What a security headers check tells you and what it misses

A security headers check inspects the browser-facing security headers for a URL or host and confirms which ones are present on the live response.^[1] It is a read of what your server sends back, nothing more. The check does not log in, submit forms or probe your code.

Security headers are instructions from your server to the visitor's browser. One tells the browser to use HTTPS only. Another tells it not to guess a file's type.^[4] The browser enforces these rules on your behalf, which limits what can go wrong on the page.

Two consequences follow from that:

• The check sees the public response. If your CDN, host or framework adds or strips a header, the result reflects what visitors receive, not what your config file says.
• A header is not a code fix. A header restricts browser behavior. A bug in your application logic stays in place whether the header is set or not.

A useful report lists at least five headers: HSTS, CSP, X-Frame-Options, Referrer-Policy and X-Content-Type-Options, and says for each whether it is present on the live response.^[1] The table covers the three with the clearest job. X-Frame-Options gets its own section below because its result is easy to misread.

Presence is only the first thing to read. Look at the values too.

For HSTS, the header makes the browser upgrade future HTTP attempts to HTTPS automatically, and its max-age value is the time in seconds the browser remembers that rule.^[6] A report that shows the max-age lets you see how long that memory lasts.

For CSP, the main use is controlling which resources a document may load, JavaScript in particular.^[5] That makes CSP the header most tied to how your site is built. A policy that fits one app can break another, so a report can tell you a policy is missing but cannot write the right one for you.

A green tick next to X-Frame-Options does not by itself mean the browser is acting on it. MDN documents an obsolete directive for this header and states that modern browsers that encounter a response header with that directive ignore the header completely.^[2] A check that only tests for presence will not catch that.

When a report shows X-Frame-Options, whether as present or missing, do two things:

1. Read the header's actual value and compare it with the directives MDN lists as current.
2. Check whether your Content-Security-Policy sets a frame-ancestors directive, and read the two results together.

This keeps you from fixing a warning by adding a header the browser will not use.

A headers grade reflects which recommended headers are set on one response. It says nothing about whether your application logic is safe. A site can return every recommended header and still let one user read another user's data.

Grades are also not comparable across tools. Snyk, for example, describes its website security score as covering which HTTP security headers are set and which recommended ones are missing, plus vulnerable versions of JavaScript libraries detected on the page.^[3] A tool that counts libraries and a tool that counts only headers can give the same site different results.

No automated result is a full security audit. We say the same about our own tool: BattleTester is not a comprehensive security audit and does not replace a professional security assessment by qualified security professionals. If your app handles payments, health data or other sensitive records, have a qualified security professional review it.

Headers are one layer, and the layers behind them only show up when something uses the application: signs in, requests pages, changes parameters and compares what each kind of user is allowed to do. A read of the response cannot do that.

BattleTester's tests work on those layers:

• Broken access control: whether users can access resources or perform actions beyond their permissions.
• XSS: reflected, stored and DOM-based cross-site scripting.
• JWT security: weak signing algorithms, missing expiration claims and improper validation in JSON Web Tokens.
• Business logic: application-specific flaws such as price manipulation, race conditions, workflow bypasses and parameter tampering.

BattleTester crawls your entire application as each user role: anonymous, logged-in and admin. A full pentest costs $15 and is charged only if the scan finds High or Critical vulnerabilities.

Run the check on your live public URL, write down what is missing, then decide which headers your app needs. In practice:

1. Enter the exact URL visitors use, so the result reflects the live response.
2. List each header reported as missing.
3. For each header reported as present, read its value and not only its status.
4. Give the X-Frame-Options line the second look described above.
5. Decide which missing headers apply to your app, add them, and run the check again.

Once the headers are in order, move on to the layers a headers check cannot see. No credit card is required upfront to start a free surface scan with BattleTester.

BattleTester's founder gives this reason for building the tool:

Related reading: How to check for CORS misconfiguration on your own site, CORS misconfiguration mitigation: fixes for each common mistake