Skip to content
Albright Labs Book a consult

Is your site served the right way?

Most site security starts with boring, invisible configuration: everything on HTTPS, a handful of headers telling browsers what to allow, and no HTTP assets sneaking onto secure pages. This audit checks the ones that matter and tells you which are missing.

  • HTTPS coverage across every page we crawl, plus mixed content
  • HSTS, Content-Security-Policy and X-Frame-Options
  • X-Content-Type-Options and Referrer-Policy
  • A per-page table, because coverage is rarely uniform

Run your free audit

No account required. We'll email your report, follow up about your results, and send Operator's Notes every two weeks. Unsubscribe anytime.

The front door, not the building.

Everything this audit flags is real, and most of it is fixed in server configuration rather than in your code, which makes it some of the cheapest security work available to you.

What it is not is a vulnerability scan. A clean score means the front door is fitted properly. It says nothing about the locks inside, and we would rather tell you that than sell you a green tick.

Security check FAQs

No. It reads how your pages are served and which security headers they send. It does not probe your application, your dependencies, your logins or your data. Those are worth doing and they are a different exercise, done by a person.

It means your transport and headers are configured well, which is a genuine and often-missing foundation. It does not mean your site is secure. Plenty of thoroughly compromised sites score well here.

A secure page loading an image, script or stylesheet over plain HTTP. Browsers either block it or warn about it, and it quietly undoes the encryption you thought you had. It is also usually a one-line fix, which is the best combination a finding can have.

Common rather than catastrophic. CSP is the most powerful header here and the most work to get right, because a strict policy can break a working site. It is worth doing deliberately, not in a hurry.

Because coverage is often not uniform. Headers set at the app level can be missing from anything served by a different route, a CDN rule, or a legacy subdirectory. The per-page table is where you find that.

Usually, and usually quickly.

Want this configured properly?

Most of what this finds is server configuration, which means it is quick to fix and easy to leave broken. We do it, and we keep it that way.

Talk to us →

A free 15-minute call. Prefer to write? Send a message.