Security & encryption
Are your visitors' connections properly protected? We check the protections visible from outside: encryption, certificates, security headers, what your site exposes, and how people can report a security problem to you.
Try our method for free
One page. One pillar. A real report.
Enter your website and we’ll email you a report on Security & encryption for your home page. Please allow at least 24 hours.
Our plans cover the 9 pillars across the pages of your whole site.
What we check
- The certificate: its validity, its expiry date, and whether it was actually issued for your domain name. A certificate issued for your host’s name triggers a browser warning on every visit.
- The TLS versions and cipher suites your server still accepts, and the redirect from the insecure address to the secure one: in force, and permanent.
- The security headers that restrict how other sites can embed your pages and control certain browser behaviors.
- The protective attributes set on session cookies, and the resources still loaded unencrypted from a page that is otherwise secure.
- The libraries and components used by your pages when their version carries a known security vulnerability.
- What your site reveals about its own construction: versions printed in headers, development files left online, error pages that say too much, and credentials that have no place in public code.
- The security.txt file, which tells anyone who finds a security problem on your site who to report it to.
What we find on the sites we audit
Across about 30 websites we audited between August 14, 2026 and September 24, 2026:
- 55% send no Content-Security-Policy
- 40% set sensitive cookies without the Secure, HttpOnly or SameSite attributes
- 40% don't make browsers stay on HTTPS (no HSTS header)
Each percentage covers the sites where the point could be checked. Many were audited because a defect showed up quickly, so these figures describe our audits, not websites in general.
See also: Domain & network, a real online store report.
On what basis
TLS (RFC 9325) · security.txt (RFC 9116)
A finding is only worth something if it rests on an identifiable basis. Where one exists, we rely on a law, a standard or a specification, and for every point recorded the report names the page and gives the value we measured.
What it changes for you
A security warning shown by the browser on your home page costs more than an invisible flaw: it stops the visitor before a single line is read, and it arrives without notice, the day a certificate expires.
The rest plays out more quietly. What a site publishes about its own construction (versions, development files, error pages) says more than it should. None of this is on display: these are technical properties of your server’s responses.
What this audit does not say
We produce a passive audit. We establish what the site shows any visitor, search engine or AI agent, never what a logged-in session would reveal, and that is precisely the point: the report describes what your customers, your partners and search engines see.
Looking for exposed files or entry points belongs to a deeper examination, with access attempts, which only takes place with the site owner’s written agreement.
Every limit of the examination is stated in the methodology note of your report. A point that cannot be verified is never presented as compliant.
The weight of this pillar
An overall score has to weigh what matters for your business: the 9 pillars do not carry the same weight depending on what your site is for. Here is what “security & encryption” represents in the overall score, under each weighting. The report always states which one produced your score.
| Type of site | Share of the overall score |
|---|---|
| Type not determined | 15% |
| Business / brochure site | 10% |
| E-commerce site | 18% |
| Application / customer portal | 25% |
| Blog / media site | 10% |
| Public-sector site | 12% |
This pillar is examined alongside the other eight in every plan, whatever the number of pages. See pricing →
Guides for this pillar
HSTS: what it protects, and what can break
HSTS makes browsers use HTTPS from the very first request. What max-age, includeSubDomains and preload do, what breaks, and what the audit reads.
Read the guide →Secure cookie attributes: what each stops
Secure, HttpOnly, SameSite: what each cookie attribute prevents, which cookies really need them, and what the audit records on your website.
Read the guide →HTTP security headers: which ones matter
HSTS, CSP, X-Frame-Options: what each HTTP security header prevents, which ones come first, and what the audit records on your website.
Read the guide →