Security Headers: What They Do and Why
Author: Domeny.ForSale editorial team Published
In brief: Security Headers are HTTP response headers that tell browsers how to handle a page securely. They help limit unwanted script execution, embedding in frames on other websites, and information disclosure when navigating between sites. They do not replace secure code or updates, but provide an additional layer of protection.
How security headers work
When a browser fetches a page, the server sends its content along with metadata: information describing the response. HTTP headers are part of this metadata. They do not appear in the page text, but the browser can use them to restrict how the resources it receives may be used.
Security headers can require an encrypted connection, specify permitted script sources, or prevent a page from being embedded in a frame on another website. They are usually set in the configuration of the server, application, reverse proxy or CDN—the infrastructure involved in delivering content.
These protections are enforced primarily by the browser. They do not prevent other tools from sending requests directly to the application, so they cannot replace server-side permission checks.
Key Security Headers and their uses
There is no single configuration suitable for every website. The following headers address different threats and need to be tailored to how the site works.
| Header | Purpose | What to watch out for |
|---|---|---|
Content-Security-Policy | Specifies permitted sources for scripts, styles and other resources, among other rules. | An overly restrictive policy can block forms, payments or analytics. |
Strict-Transport-Security | Requires the browser to use HTTPS for a specified period. | A long duration and coverage of subdomains require the entire infrastructure to be ready. |
X-Content-Type-Options | With the value nosniff, limits attempts to infer a resource type that differs from the server’s declaration. | The server must send the correct Content-Type, for example for scripts and stylesheets. |
Referrer-Policy | Controls what information about the page’s address is passed in the Referer header. | The setting should account for privacy and integration requirements. |
Permissions-Policy | Restricts access to selected browser features, such as the camera or geolocation. | Support for individual directives varies by browser. |
X-Frame-Options | Restricts embedding the page in frames. | Offers less flexibility than the frame-ancestors directive in CSP. |
CSP, or Content Security Policy, helps limit the impact of XSS: attacks that execute unwanted code in the context of a page. A list of trusted domains alone does not provide complete protection. The specific directives, how scripts are loaded, and the absence of overly broad exceptions all matter.
The frame-ancestors directive in CSP is one way to protect against clickjacking: tricking a user into clicking an element of a page concealed within another website. It can prohibit embedding entirely or allow only specified websites to embed the page.
Example: a page with a form and external services
Suppose a company website uses a contact form, a map and an external analytics tool. Introducing a CSP that allows only resources from the site’s own domain may disable the map and analytics. Before deploying it, you therefore need to identify where the page loads scripts, styles, images and frames from, and where it sends requests.
If the site should not be embedded in any frame, an example policy fragment looks like this:
Content-Security-Policy: frame-ancestors 'none'
This is only a rule governing embedding, not a complete CSP. It does not restrict script sources or network connections. If the site already has a CSP, carefully integrate the rule into the existing configuration rather than adding another policy without checking how they interact.
For a page that does not need a camera or microphone, you could consider:
Permissions-Policy: camera=(), microphone=()
Do not copy this setting into an application that supports video calls. A well-chosen header restricts unnecessary capabilities, not features the user needs.
How to check and safely deploy headers
The simplest approach is to open your browser’s developer tools, go to the network tab, refresh the page and select the request for the main document. The response headers section shows what the browser actually received. An entry in the server configuration does not necessarily mean that the header reaches the user.
A practical deployment sequence:
- Check representative URLs: the home page, login page, forms and error pages. Their responses may pass through different infrastructure layers.
- Identify where you manage headers. The application, server and CDN should not inadvertently overwrite settings or add conflicting rules.
- Prepare a CSP in
Content-Security-Policy-Report-Onlymode. This lets you observe violations without blocking resources; collecting reports requires additional configuration. - Test key user actions, including logging in, submitting a form and making a payment, where applicable.
- Enable policy enforcement and monitor errors after deployment.
Deploy HSTS, the mechanism enabled by Strict-Transport-Security, only once HTTPS is working reliably. The includeSubDomains parameter also covers subdomains, so check less obvious services before using it. Confirm current syntax and directive support in the official documentation for your platform and browsers.
What a security scanner score does not tell you
A scanner can detect a missing header or a risky value, but its assessment does not prove that an application is secure. Some policies are needed only for particular uses, and adding them to improve a score can break integrations.
Headers will not fix incorrect permissions, database vulnerabilities or secrets exposed in code. Start by checking your site’s actual responses and choose one change whose behavior you can verify before deploying it.
See also: What is CSP?
Read also
