Security headers check — HSTS, CSP, clickjacking and cookie flags tested by SecQon

Security headers are instructions your server sends to the browser: always use HTTPS, only run scripts from these places, never show this page inside someone else’s frame. SecQon checks that each one is present and that its value actually does something — a header browsers ignore is reported, not counted as protection. The check reads a normal page load with ordinary HTTPS GET requests and runs on every plan.

Runs on: Light, and therefore also Standard and Deep. Runs on every plan and on the free instant check. Deep scans extend it to every crawled page.
Included from: Free plan ($0)
OWASP Top 10 (2021): A05

What we test

Finds a real page first
Follows up to three redirects on the same host to reach an actual page. Headers are never judged on a redirect response, and a redirect to another host is noted rather than followed.
HSTS present and long enough
Reports a missing Strict-Transport-Security header, and a max-age under six months, which is too short to protect a first-time visitor.
Content-Security-Policy present and effective
Reports a missing CSP, a policy that does not restrict script sources, one that allows scripts from any origin, and one that allows inline scripts.
Clickjacking protection
Checks for X-Frame-Options or a CSP frame-ancestors rule, and reports a value browsers do not act on.
X-Content-Type-Options
Reports the header when it is missing, or present with any value other than nosniff.
Referrer-Policy
Reports a missing policy, and a policy that still sends the full URL — paths and query strings included — to other sites.
Cookie flags
Reports cookies set without the Secure or HttpOnly flag. SameSite is checked separately by the authentication-configuration check on Standard scans.
Server version disclosure
Reports a Server or similar header that names a software version, which tells an attacker exactly which advisories to look up.
Every crawled page on Deep
On Light and Standard the check reads your resolved homepage. On Deep it reads every same-host page the crawl finds, and skips browser-hardening verdicts on responses that are not HTML.

Why it matters

Most of these headers exist to make a whole class of attack stop working without you changing a line of application code. HSTS stops a visitor on café Wi-Fi from being quietly downgraded to plain HTTP. A working Content-Security-Policy means that if someone does manage to inject a script into your page, the browser refuses to run it. Clickjacking protection stops another site loading your page invisibly and tricking your users into clicking buttons on it. None of them fixes a bug, but each one limits how much damage a bug can do.

They are also the first thing anyone checks. Customers’ security teams, auditors and security questionnaires look at your headers because they can do it in seconds from outside, and a site with none of them sends a signal about everything else. We learned that ourselves: the first time we scanned SecQon with SecQon, neither our website nor our API sent any of the five main security headers.

A header being present is not the same as it working. An HSTS max-age of a few minutes, or a CSP that allows scripts from anywhere, looks fine on a checklist and protects almost nothing. That is why SecQon reports ineffective values as findings in their own right, with the exact header in the evidence.

An example finding, and its fix

A finding of a type this check really produces. The evidence is illustrative, not taken from a customer's scan.

Medium

Content-Security-Policy allows scripts from any origin

Evidence

GET https://app.example.com/ → 200 OK
content-type: text/html; charset=utf-8
content-security-policy: default-src 'self'; script-src 'self' *; object-src 'none'

How to fix it

List the origins your pages really load scripts from (your own domain, your analytics or payment provider). Replace the wildcard in script-src with those origins, for example: script-src 'self' https://js.stripe.com Deploy it first as Content-Security-Policy-Report-Only if you are unsure, and watch for violations. Switch to the enforcing header and re-test the finding from your report.

What we don't test

A design review of your Content-Security-Policy. We report a fixed list of faults we can decide from outside; we do not judge whether your policy is well designed.
Pages beyond your resolved homepage on Light and Standard scans — only Deep crawls and checks other pages.
Whether HTTP redirects to HTTPS. Our scanner only connects over TLS, so the plain-HTTP redirect is not tested.
A host your homepage redirects to. We note the destination and stop; add that host as its own asset to have it checked.
SameSite on cookies in this check — it is covered by the authentication-configuration check on Standard and Deep.

Every report names what its scan did and did not assess. See the full OWASP Top 10 coverage, including the two categories no external scan can assess.

Security headers & cookies: questions people ask

Which security headers does SecQon check?

Strict-Transport-Security, Content-Security-Policy, X-Frame-Options or CSP frame-ancestors, X-Content-Type-Options and Referrer-Policy, plus the Secure and HttpOnly flags on cookies and any Server header that discloses a version.

Does SecQon only check whether headers exist?

No. It also reports headers that are present but ineffective: an HSTS max-age under six months, a CSP that allows scripts from any origin or inline scripts, and clickjacking or nosniff values that browsers ignore.

Is the headers check safe to run on production?

Yes. It reads your page with ordinary HTTPS GET requests, the same as a browser loading it, and follows at most three redirects on the same host.

Why does my report say security headers were not assessed?

Because your address redirects to a different host. We do not judge headers on a redirect, and we do not follow it off your verified host. The note names the destination; verify that host too if it is yours.

Will SecQon check headers on every page of my site?

On Deep scans, yes — every same-host page the crawl finds. Light and Standard scans check the resolved homepage.

Do you give configuration I can copy?

Yes. Remediation includes hand-written configuration for nginx, Apache, Caddy, IIS, Express, Next.js, Django, PHP and Cloudflare, plus a generic version.

Other checks

TLS & certificates
Certificate trust and expiry, and whether your server still accepts TLS 1.0 or 1.1.
DNS & email security
SPF, DMARC, CAA and DNSSEC — the records that stop spoofed email and mis-issued certificates.
Exposed ports & services
36 high-risk TCP ports — databases, container control planes, remote admin — checked with one connect each.
API security
Your API’s own schema, read as an outsider: open operations, GraphQL introspection, CORS and leaked stack traces.
Web application pentest
A browser-rendered crawl plus bounded proofs for XSS, SQL injection and SSRF, and an active scanner on the pentest tier.

Last reviewed against our scanning documentation on 24 Sep 2026.

See what a scan finds on your own asset

Free for one verified asset, no card needed. Paid plans add the written report, more assets and deeper scans.

Start free Compare plans

Security headers check — HSTS, CSP, clickjacking and cookie flags tested by SecQon

What we test

Finds a real page first

HSTS present and long enough

Content-Security-Policy present and effective

Clickjacking protection

X-Content-Type-Options

Referrer-Policy

Cookie flags

Server version disclosure

Every crawled page on Deep