Online Tool Store
· 5 min read
How to Grade Security Headers and Spot the WAF Behind Them
Heshan Fernando
Co-founder & COO
You’ve inherited a client’s website, and before touching anything, you want a quick read on how it’s currently protected. Are the basic security headers present or missing entirely? Is there a WAF or CDN sitting in front of it already, or is the origin server directly exposed? Both questions are answerable from response headers alone, but manually cross-referencing header names against what different providers add is slow and easy to get wrong.
This comes up constantly during a security audit, a pre-migration checklist, or just due diligence before you agree to take over maintenance on something you didn’t build. You want a fast overall grade, not a header-by-header manual review every time — and you want to know if there’s already a WAF in front of the origin, because that changes what protections you actually need to add versus what’s already handled upstream.
What a headers-and-WAF audit actually involves
Grading security headers means checking a response against a baseline set of commonly recommended headers — HSTS, CSP, X-Content-Type-Options, and others — and scoring how complete and reasonably configured that set is. Detecting the WAF or CDN is a separate but related task: providers like major CDN and firewall services often leave identifying fingerprints in response headers, even when they’re not trying to advertise themselves — a specific header name, a particular Server value, or a distinctive cookie pattern.
Together, these two checks answer a practical question fast: is this site’s edge layer doing its job, and who’s actually operating it? That matters because a missing header behind an active WAF might already be mitigated at the edge, while the same missing header on an unprotected origin is a real gap.
Why people get stuck here
- Headers alone don’t tell you who’s fronting the site. You have to know the specific fingerprints each WAF/CDN provider leaves, which isn’t public knowledge in one place.
- A grade without context is misleading. A “C” grade on headers might be fine if a capable WAF is already blocking the underlying attacks the missing headers would mitigate — or it might mean nothing is protecting the origin at all.
- Different environments show different headers. Staging, a CDN-fronted production domain, and a direct origin IP can all return different header sets for the same underlying app, and comparing them without noting that leads to wrong conclusions.
- Manually running this check per client or project doesn’t scale, especially during a broader audit covering a dozen sites.
What a good header-and-WAF auditor looks like
Produces a clear grade, not just a raw header dump
A letter grade or score gives you a fast triage signal before diving into specifics — useful when you’re screening many sites and only have time to investigate the worst-graded ones in depth.
Identifies the WAF/CDN from the same header set
Detecting the fronting provider from the same paste you used for the grade saves a second manual lookup and gives you the fuller picture in one pass.
Works from pasted headers, not a live scan against the target
Auditing from headers you’ve already captured — rather than the tool making its own live request to the target — avoids adding unnecessary traffic to a site you may not have permission to actively scan.
| Signal | What It Tells You | Watch Out |
|---|---|---|
| Header grade | Baseline completeness of the site’s own header configuration | A high grade doesn’t guarantee correct values, just presence |
| Detected WAF/CDN | Whether an edge layer is already mitigating common attacks | Detection isn’t always possible if the provider is configured to hide fingerprints |
| Missing headers list | Specific gaps to raise with the site owner or fix directly | Some gaps may already be covered upstream by the WAF |
Common mistakes to avoid
- Grading a staging or CDN-cached response and assuming it reflects the production origin’s actual configuration.
- Treating a missing header as an unmitigated gap without checking whether an active WAF already covers that risk.
- Running an intrusive scan against a site you don’t have explicit permission to test, instead of working from headers you already have legitimate access to.
- Assuming an unrecognized WAF fingerprint means there’s no WAF at all — some providers are harder to fingerprint than others.
- Comparing grades across sites captured at different times without accounting for header configuration changes in between.
How to audit headers with Security Headers & WAF Auditor
Online Tool Store’s Security Headers & WAF Auditor works entirely from headers you paste in, in your browser.
- Capture the response headers from the site you’re auditing, using your browser’s dev tools or a request tool you already trust.
- Paste them into the tool.
- Review the overall header grade and the list of missing recommended headers.
- Check the detected WAF/CDN provider against what you expected for that site.
Frequently asked questions
Can this tool scan a website for me automatically?
No — it works from response headers you’ve already captured and paste in, which keeps the audit strictly to headers you have legitimate access to rather than making the tool itself issue requests to a target you may not have permission to actively scan.
Why would a site with a good header grade still be vulnerable?
A grade reflects presence and rough configuration of headers, not the full security posture of the application. Headers are one layer among many — a well-graded site can still have vulnerabilities elsewhere, like in application logic or authentication.
How reliable is WAF/CDN detection from headers alone?
It’s reliable for providers that leave clear, consistent fingerprints, but not universal — some setups deliberately obscure or don’t add identifying headers, in which case detection may come back inconclusive rather than wrong.
Final thought
A grade and a WAF detection together tell you more than either alone — before recommending new headers to a client, confirm whether something upstream is already covering that gap.