Security headers meaning: what they are and why they matter

Security headers are a small set of HTTP response headers that switch on protections built into the browser. Once set, OWASP says, they "can restrict modern browsers from running into easily preventable vulnerabilities."^[2] They don't change how your page looks. They change what the browser will allow that page to do.

Content-Security-Policy (CSP) is a good example. According to MDN, it "allows website administrators to control resources the user agent is allowed to load for a given page."^[3] If your policy says scripts may only come from your own domain, the browser refuses to run a script injected from anywhere else. CSP is not new or experimental: it has been available across browsers since August 2016.^[3]

Security headers matter because the browser does the enforcing, and it only enforces what you ask for. If a header is missing, that protection is simply off. Your code may be fine, but the browser has no instruction to stop a malicious frame, an injected script or an insecure connection.

Take HSTS (Strict-Transport-Security). OWASP describes it as a mechanism that "helps to protect websites against protocol downgrade attacks."^[1] Without it, a browser may still try a plain HTTP connection first, which gives an attacker on the same network a window to intercept traffic. With it, the browser remembers to use HTTPS for your domain.

This is the core value: headers are cheap to add, they apply to every visitor, and they close off whole classes of attack the browser already knows how to stop.

Three headers do most of the work on a typical web page: Strict-Transport-Security, Content-Security-Policy and X-Frame-Options. The table below maps each one to the risk it addresses, plus two headers that matter most for APIs.

Many checklists also include X-Content-Type-Options and Referrer-Policy. For what each header does, example values and where to add them in your stack, see our guide on how to set up security headers in a web application.

The fastest way to check your security headers is a free online scanner. The best known is securityheaders.com, described as "a free and easy to use tool designed to help you better deploy and understand modern security features."^[5] It is now part of Snyk and was originally created by Scott Helme,^[5] which is why you will see it called "security headers by Snyk" or "security headers io."

You can also check by hand. Open your browser's developer tools, go to the Network tab, reload the page and select the main document request to see its response headers. Several browser extensions show the same information in one click. If you install one, check who publishes it first, since extensions can read the pages you visit.

A header check is a quick yes or no on each header. For what that result can and cannot tell you, read what a security headers check tells you and what it misses. If you want a broader first look at your app, you can start a free surface scan with us, and no credit card is required.

Most browser-focused security headers do little for a pure JSON API. OWASP's REST Security Cheat Sheet says those headers "are only intended to provide additional security when responses are rendered as HTML."^[4] A JSON response is not rendered as a page, so there is no script to restrict.

For APIs, focus on these instead:

• Cache-Control: no-store on sensitive responses. It instructs private and shared caches "not to store the response or reuse it for another request."^[4]
• CORS kept closed by default. OWASP's advice is to "disable CORS headers if cross-domain calls are not supported/expected."^[4] A wide-open CORS setting lets any website call your API from a visitor's browser.
• frame-ancestors still has a role, because it "protects against drag-and-drop style clickjacking attacks."^[4]

The full checklist, including how to test each one, is in security headers for APIs: what to set and test.

A perfect header scan means your browser protections are switched on. It does not mean your app is secure. Header scanners read your responses from the outside, so they cannot tell whether a logged-out user can reach an admin endpoint, whether one customer can view another customer's data, or whether a checkout can be tricked into a lower price.

Missing headers are often the first visible sign of that gap, and the deeper problems sit in access control and business logic. A full BattleTester scan crawls your application as each user role: anonymous, logged-in and admin. It tests for broken access control, meaning users reaching resources or actions beyond their permissions, and for business logic flaws such as price manipulation, race conditions, workflow bypasses and parameter tampering.

If you built on a hosted platform, the same principle applies to its built-in checks. See what the Replit Security Agent covers and what it leaves to you.

BattleTester is not a comprehensive security audit and does not replace a professional security assessment by qualified security professionals. For an app that handles payments or sensitive personal data, plan for that assessment as well.