How to Check Your Website's Security Headers (and What Each One Actually Stops)
One curl command shows you every security header your site sends. This guide is the decoder: what each header stops, what its absence costs, and the three that matter most.
Webcuris Research
Security Engineering
·2 min read
Checking your website's security headers takes one command and thirty seconds. Understanding what came back is the part every checklist skips — which header stops which attack, which absences are urgent, and which are noise. This guide is the decoder.
The thirty-second check
curl -sI https://example.com | grep -iE \
'strict-transport|content-security|x-content-type|x-frame|referrer-policy|permissions-policy|set-cookie'What each header actually stops
| Header | The attack it stops | If it is missing |
|---|---|---|
| Strict-Transport-Security | SSL stripping — intercepting the first plaintext request | One coffee-shop network between you and a user is enough (full guide) |
| Content-Security-Policy | Injected scripts executing (XSS) | Any reflected or stored injection runs — and note that a CSP containing 'unsafe-inline' stops almost nothing |
| X-Content-Type-Options: nosniff | Browsers reinterpreting a response as a richer type | An upload served as text can be sniffed into something executable |
| X-Frame-Options / frame-ancestors | Clickjacking — your UI framed invisibly under someone else's buttons | Your logged-in pages can be embedded and overlaid anywhere |
| Referrer-Policy | Full URLs leaking to third parties | Path and query strings — tokens included — travel in the Referer header |
| Permissions-Policy | Injected or third-party code using camera, mic, geolocation | Powerful APIs stay available to every script on the page |
Cookies are headers too
The Set-Cookie line carries its own security surface, and it is worth reading attribute by attribute:
Set-Cookie: session=…; Secure; HttpOnly; SameSite=Lax; Path=/- Secure — never sent over plain HTTP. Without it, one non-HTTPS request exposes the session.
- HttpOnly — invisible to JavaScript. Without it, any XSS reads the session cookie directly, turning a script bug into full account takeover.
- SameSite — not attached to cross-site requests. Without it, other sites can ride the session (CSRF).
Reading the result honestly
Presence is the start of the check, not the end of it. A Strict-Transport-Security with max-age=300 protects a visitor for five minutes. A CSP whose `script-src` includes `'unsafe-inline'` reports as present and defends against approximately nothing. Two questions for every header you find: is the value strong enough to do its job, and is it on every response — including error pages, which are exactly where several servers quietly drop custom headers.
Then stop checking by hand
The curl command answers today. Headers regress: a config refactor, a CDN migration, a new load balancer — most missing-header findings on established sites are things that used to be there. A free Webcuris scan reads every header above, judges the values rather than the presence, and shows the exact fix for each gap; monitoring re-checks daily and tells you the day a deploy drops one.
Keep reading
Secure, HttpOnly, SameSite: Cookie Attributes Explained by What Goes Wrong Without Them
Three attributes, three specific attacks. What each one stops, what happens on the day it is missing, and the one line of Set-Cookie a session cookie should carry.
A Content-Security-Policy That Reports as Present and Defends Nothing
A script-src carrying 'unsafe-inline' passes every presence check and stops no injection. The theatre policy, the working one, and the war story of a strict CSP that broke sign-up with no error anywhere.
Missing HSTS Header: What It Means, How to Fix It, and How to Prove You Fixed It
The cheapest finding on your report to fix — one header — and the easiest to get wrong in three specific ways. The exact fix for nginx, Apache, Caddy and Next.js, and how to prove it worked.