Quick and Standard profiles
HTTP security headers
HTTP security headers are instructions a website sends with every response, telling the browser how to behave: whether to insist on HTTPS, which scripts may run, whether the page may be framed, how much referrer information to leak. Missing or weak headers are the most common finding on any website, and among the cheapest to fix.
What the check does
ScanBastion requests the home page and a sample of pages discovered during the crawl, then inspects the response headers of each. For every header below it records whether the header is present, what its value is, and whether that value is actually protective. A header that is present but set to a value that disables the protection, such as X-Frame-Options: ALLOWALL or a Content-Security-Policy consisting only of default-src *, is reported as weak rather than counted as a pass.
This is a read-only check. It sends the same requests a browser sends when a visitor loads the page, at a bounded rate, and nothing else.
Headers assessed
| Header | Protects against | Typical severity when missing |
|---|---|---|
Strict-Transport-Security | Protocol downgrade and cookie theft over plain HTTP | Medium |
Content-Security-Policy | Cross-site scripting and injection of untrusted scripts, frames and styles | Medium |
X-Frame-Options / frame-ancestors | Clickjacking | Medium |
X-Content-Type-Options | MIME-type sniffing turning uploads into executable content | Low |
Referrer-Policy | Leaking full URLs, including tokens, to third parties | Low |
Permissions-Policy | Unwanted use of camera, microphone, geolocation and similar APIs by embedded content | Info |
Cross-Origin-Opener-Policy | Cross-window attacks on pages that hold secrets | Info |
Set-Cookie flags | Cookies sent over HTTP, read by scripts, or sent with cross-site requests (Secure, HttpOnly, SameSite) | Medium for session cookies |
Server, X-Powered-By | Version disclosure that helps an attacker pick exploits | Info |
Headers that browsers have retired, such as X-XSS-Protection, are not reported as missing, because adding them achieves nothing and in some browsers once caused harm.
How severity is assigned
Severity reflects what the missing protection would allow, not how easy the fix is. A missing Strict-Transport-Security on a site that handles log-ins matters more than on a brochure site, so the check raises the severity when the crawl finds log-in or account pages, and lowers it for a purely static site. Confidence for header findings is almost always high: the header is either there or it is not. The exception is Content-Security-Policy, where the check can tell you a policy is absent or permissive, but only a person reading the policy against the application can say whether it is effective.
An example finding
/account · Confidence: High · Needs reviewThe response sets
PHPSESSID without the Secure attribute. Because the site is also reachable over plain HTTP, the browser will send the session cookie in clear text if any resource is ever requested over HTTP. Remediation: set Secure and HttpOnly on the session cookie, add SameSite=Lax, and redirect HTTP to HTTPS at the server.What this check cannot tell you
- Whether a Content-Security-Policy is correct. It can say the policy is missing, uses
unsafe-inline, or allows wildcards. It cannot know whether the allowed sources are the ones the application needs or whether a nonce scheme is implemented properly. - Headers on pages it cannot reach. The crawl is unauthenticated, so headers on pages behind a log-in are not observed.
- Behaviour of a CDN or WAF. Some edges add or strip headers depending on the request, the geography or the cache state. The check reports what it observed from where it scanned.
- Whether the application is vulnerable. A missing CSP does not mean there is a cross-site scripting bug; it means that if there were one, the browser would not help.
Fixing header findings
Most header findings are fixed in the web-server or CDN configuration rather than in application code, which is why they are a good first deliverable for an agency: a few lines of nginx, Apache or edge-rules configuration clear several findings at once. The guide HTTP security headers explained for agency developers gives a safe starting value for each header and names the two that will break a site if set carelessly. Then rescan to confirm.
References
- OWASP Secure Headers Project, the reference list and recommended values.
- MDN HTTP headers reference, with browser support for each directive.