Most conversations about website security focus on things like software updates, passwords, firewalls, backups and malware scanning.
Security headers work in a different part of the equation. They are instructions sent with a website’s response that tell the browser how it should handle certain parts of the page.
Depending on the header, those instructions can restrict where scripts are allowed to load from, prevent a website from being embedded inside another site, enforce secure connections or limit what information is shared when someone follows a link.
They do not fix vulnerable code or replace a broader security strategy. What they provide is another layer of protection in the browser, where attacks such as cross-site scripting and clickjacking actually play out.
What security headers actually do
When someone visits a website, the server sends back more than the HTML that eventually appears on screen. The response also includes HTTP headers containing information and instructions for the browser.
Security headers use that mechanism to set boundaries. A site can tell the browser which sources are trusted to load JavaScript, whether the page can be embedded on another domain, how HTTPS should be handled and whether the browser should try to reinterpret a file as something other than the type declared by the server.
The basic idea is simple: instead of relying entirely on default browser behavior, the website provides a clearer set of rules for what should and should not be allowed.
The risks they address are common
It is difficult to put a single number on how many attacks security headers prevent. They are defense-in-depth controls, and a missing header is rarely recorded as the sole cause of a security incident.
There are, however, some useful numbers that show why the problems they help address still matter:
- Cross-site scripting ranked first in MITRE’s 2025 list of the 25 most dangerous software weaknesses.
- OWASP’s 2025 Injection data includes more than 30,000 CVEs associated with cross-site scripting.
- Despite the protection Content Security Policy can provide, HTTP Archive found that only 21.9% of sites measured in 2025 were using CSP.
Those numbers do not mean security headers would have prevented every vulnerability represented in the data. They do show that browser-side security issues remain common while some of the protections available to limit their impact are still far from universally used.
The security headers worth knowing about
There are several security-related headers, but a handful come up regularly in the sites I build and audit:
- Content-Security-Policy: Controls which sources the browser is allowed to trust for scripts, styles, images, fonts, frames and other resources. CSP is powerful, but it requires more care than most headers because modern websites often depend on analytics, video, maps, fonts and other third-party services. I generally begin in reporting mode so legitimate dependencies can be understood before moving toward enforcement.
- Strict-Transport-Security: Tells supporting browsers to use HTTPS for future connections to the site.
- X-Content-Type-Options: Prevents the browser from ignoring a declared content type and trying to interpret a file as something else.
- Referrer-Policy: Controls how much information about the current page is shared when the browser makes requests or someone follows a link.
- Permissions-Policy: Restricts access to browser features such as the camera, microphone or geolocation when they are not needed.
- Framing controls: X-Frame-Options and CSP’s frame-ancestors directive can restrict where a page is allowed to be embedded, helping protect against clickjacking.
Each of these controls a fairly specific part of browser behavior. Together, they give the browser clearer boundaries and reduce unnecessary exposure to certain types of attack.
An invisible security baseline
Security headers are easy to overlook because a website can look and function perfectly without them. They are not a complete security strategy, but they add a useful layer of browser protection without changing how visitors use the site. Most people will never know they are there, which is exactly how a good security baseline should work.
Curious about the state of the security headers on your website? Run a quick scan at SecurityHeaders.com opens in a new tab.