Security headers
Security headers are HTTP response headers a web server sends to tell the browser how to handle a page more safely. Headers like Content-Security-Policy, Strict-Transport-Security, and X-Content-Type-Options reduce the blast radius of common web attacks such as cross-site scripting, clickjacking, and protocol downgrades.
What a security header changes.
When a browser loads a page, it reads the response headers before it renders anything. A security header sets a rule the browser then enforces, like which scripts may run, whether the page can be framed by another site, or whether the connection must stay on HTTPS. The page works the same way for users, but the browser refuses the unsafe behavior an attacker would need.
The catch is that these headers are off by default. A site is not protected until the server is configured to send them with the right values, and a weak value (a permissive Content-Security-Policy, for example) can give a false sense of safety. That is why a scan checks both whether each header is present and whether the value actually does something useful.
The headers worth checking first.
A handful of headers cover most of the value. Each one closes a specific class of attack, and missing or misconfigured ones are some of the easiest issues to find and fix on a live site.
| Header | What it does | What it guards against |
|---|---|---|
| Content-Security-Policy | Limits which scripts, styles, and resources the page may load | Cross-site scripting and injected content |
| Strict-Transport-Security | Forces the browser to use HTTPS for future visits | Protocol downgrade and HTTPS stripping |
| X-Content-Type-Options | Stops the browser from guessing a resource's type | MIME-type confusion attacks |
| X-Frame-Options | Controls whether other sites can embed the page in a frame | Clickjacking |
| Referrer-Policy | Controls how much URL data is sent in the Referer header | Leaking sensitive paths to third parties |
Newer policies like Cross-Origin-Resource-Policy and Permissions-Policy build on the same idea: ship a small instruction with the response and let the browser enforce it.
How AuditWard relates.
AuditWard inspects response headers as part of its security pass, using tooling like curl and WhatWeb to see exactly what your server sends. When a header is missing or set too loosely, the Analyst agent raises a finding, scores its confidence, and tags it to the frameworks it touches, such as OWASP Top 10 and PCI DSS 4.0. The same run also QA-tests the site in a real browser. For the full scanning picture, see the website security scanning pillar, and the related entries on DAST and vulnerability scanning.
Security header questions.
What are security headers in simple terms?
They are short instructions a web server adds to its HTTP responses that tell the browser how to handle the page more safely. Examples are Content-Security-Policy and Strict-Transport-Security. The page looks the same to users, but the browser blocks the unsafe behavior an attacker would rely on.
Do security headers make a site secure on their own?
No. They harden the browser side of things and close several common attack paths, but they do not fix flaws in your application logic, authentication, or server configuration. Treat them as one layer that lowers risk, not a complete defense.
How does AuditWard check security headers?
During a scan, AuditWard reads the response headers your server actually sends and flags ones that are missing or set too loosely. Each issue becomes a triaged finding with a confidence score and tags to frameworks like OWASP Top 10 and PCI DSS 4.0.