ReferenceBeginner3-5 min reference
Security Headers
A handful of HTTP response headers harden a web app against common attacks. You can check every one of these in the browser DevTools Network → Headers tab or a curl -I — no special tooling, no exploitation. This is a lookup of what each header does and what "good" looks like. For the broader picture, see OWASP Top 10 below.
Header reference
| Header | Protects against | Good value looks like |
|---|---|---|
| Strict-Transport-Security (HSTS) | Protocol-downgrade / SSL strip | max-age=31536000; includeSubDomains |
| Content-Security-Policy (CSP) | XSS, injection | A policy without unsafe-inline/* on script-src |
| X-Content-Type-Options | MIME sniffing | nosniff |
X-Frame-Options / CSP frame-ancestors | Clickjacking | DENY or SAMEORIGIN |
| Referrer-Policy | Referrer leakage | strict-origin-when-cross-origin or stricter |
| Permissions-Policy | Unwanted API access (camera, geo) | Only the features the app needs |
| Set-Cookie flags | Session theft | Secure; HttpOnly; SameSite=Lax/Strict |
What QA can safely check
- The header is present on the right responses (HSTS on HTTPS; CSP on HTML documents).
- Session cookies carry
Secure,HttpOnly, and aSameSitevalue. - CSP isn't effectively disabled by
unsafe-inline,unsafe-eval, or a wildcard source. X-Powered-By/ verboseServerheaders aren't leaking stack versions.
When to use
A fast pre-release check, or while reviewing a page in DevTools. Use the request-header-inspector utility for a quick read. Probing CSP bypasses or framing attacks is security-team work, not this checklist.
Common mistakes
- Checking the homepage only — headers must be on API and authenticated responses too.
- Seeing a CSP header and assuming it's strong; read the directives.
- Confusing request and response headers.
- Treating missing headers as a "bug" without knowing the threat model — log it, link OWASP, let the team rank it.
// Related resources