HTTP Security Headers Every Website Should Implement, and Why Each One Matters
A website can use HTTPS and still lack important browser-side protections. HTTP security headers help address that gap by telling browsers how to handle connections, scripts, embedded pages, and other potentially risky content. The right configuration strengthens security, but each header has a specific purpose and must be applied in the context of the website.
In this post
1. What HTTP security headers do
When a browser requests a web page, the server returns an HTTP response containing a status code, headers, and often a response body. Headers communicate information about the response, such as its content type, caching behavior, and security requirements.
Security headers use this mechanism to activate or communicate browser-enforced policies. Depending on the header, a policy can restrict insecure connections, limit the origins from which a page loads resources, control whether another site can embed a page, or reduce the amount of browsing information shared with external destinations.
These controls are useful because browsers can enforce them without requiring every page to implement the same protection independently. However, a header only addresses the risks covered by its particular policy. It cannot compensate for every vulnerable application component, insecure server configuration, or compromised user device.
| Header or directive | Primary purpose |
|---|---|
| Strict-Transport-Security | Instructs browsers to use HTTPS for future connections to the host. |
| Content-Security-Policy | Restricts permitted resource sources and browser behaviors. |
| X-Content-Type-Options | Prevents certain MIME-type sniffing behavior. |
| CSP frame-ancestors | Controls which sites may embed a page in a frame. |
| Referrer-Policy | Controls how much referrer information browsers send. |
| Permissions-Policy | Restricts access to supported browser features. |
2. Strict-Transport-Security (HSTS)
HTTPS encrypts traffic between a browser and a website, helping protect information against interception and modification in transit. A website that supports HTTPS may still receive an initial request over HTTP when a visitor enters a domain without specifying a protocol or follows an outdated link.
HTTP Strict Transport Security, usually called HSTS, tells a supporting browser to use HTTPS for future requests to the host for the period specified by the policy. Once the browser has learned the policy, it can upgrade later HTTP attempts before sending them over the network.
A typical header looks like this:
Strict-Transport-Security: max-age=31536000
The max-age value is measured in seconds. In this example, the browser remembers the policy for one year after receiving it. A site can also include includeSubDomains to extend the policy to its subdomains:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Only use includeSubDomains when every affected subdomain is prepared to serve HTTPS. An overlooked legacy service or subdomain that cannot support HTTPS may become inaccessible to browsers enforcing the policy.
HSTS does not replace a valid TLS certificate, proper HTTPS configuration, or secure application design. It also does not protect the first connection to a domain before the browser has learned its policy, unless the domain is covered by a supported browser preload list.
Before enabling HSTS: confirm that HTTPS works reliably across the entire host and, if applicable, all subdomains. Browser preload is a separate, more demanding commitment and should not be enabled simply to improve a security score.
3. Content-Security-Policy (CSP)
Cross-site scripting (XSS) occurs when an application allows untrusted content to execute as script in a page. This can expose page data or allow unauthorized actions through the user's browser. Content Security Policy provides an additional layer of defense by defining which resource sources and browser behaviors are allowed.
For example, a policy can restrict scripts to approved sources, prevent plugins, block embedded frames, and prohibit certain unsafe execution patterns. A simple illustrative policy is:
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
This example establishes several restrictions, but it is not a complete policy for every website. It does not explicitly permit all the image, font, style, script, API, or media sources a modern site may require. Existing functionality may stop working if the policy is deployed without accounting for those dependencies.
Inline JavaScript, third-party analytics, advertising tags, embedded video, and content delivery networks can all affect the policy a site needs. A well-designed CSP should specify the minimum resources required rather than automatically allowing every source.
Use report-only mode during testing
Websites can test a proposed policy with Content-Security-Policy-Report-Only. This mode reports policy violations without enforcing the restrictions, allowing developers to identify legitimate resources that would otherwise be blocked.
After reviewing the reports and testing the site, the policy can be deployed for enforcement. Report-only mode is a testing aid, not a substitute for eventually enforcing a suitable policy.
CSP is most effective when combined with safe output encoding, secure DOM practices, careful handling of untrusted input, and other application-level defenses. It reduces the impact of some mistakes but does not make vulnerable code safe by itself.
4. X-Content-Type-Options
Browsers use the response's content type to determine how to interpret a resource. MIME-type sniffing occurs when a browser attempts to infer a resource's type rather than relying entirely on the declared type. In certain circumstances, incorrect content types can create security problems, especially when a site serves user-controlled files.
The following header tells supporting browsers not to perform certain types of MIME sniffing:
X-Content-Type-Options: nosniff
The protection is particularly relevant when servers handle JavaScript, stylesheets, and uploaded files. The server should also return the correct Content-Type for each resource and separate untrusted user uploads from sensitive application content where appropriate.
This header is not a file-scanning system. It does not establish that a file is harmless, prevent every form of content injection, or replace safe upload validation. It works best as one part of a consistent file-handling policy.
5. Clickjacking protection: frame-ancestors and X-Frame-Options
Clickjacking is a technique in which a malicious page attempts to trick a user into interacting with a different page embedded within it. For example, an attacker may place an apparently harmless interface over a framed page containing an account setting or another sensitive control.
Websites can reduce this risk by controlling which origins are permitted to embed their pages. The modern approach is the CSP frame-ancestors directive.
To prevent a page from being embedded by any site, a response can include:
Content-Security-Policy: frame-ancestors 'none'
If a page should only be framed by pages from the same origin, the policy can instead use:
Content-Security-Policy: frame-ancestors 'self'
An older compatibility mechanism is:
X-Frame-Options: DENY
The DENY value prevents framing, while SAMEORIGIN permits framing by the same origin. For modern browsers, CSP's frame-ancestors provides more flexible control. Sites that need compatibility with older browsers may choose to configure both appropriately.
Do not disable framing without checking how the site works. Payment providers, identity services, embedded tools, and other integrations may depend on legitimate framing behavior. Also note that frame-ancestors is delivered as an HTTP response header; placing it inside a CSP meta element does not provide the same protection.
6. Referrer-Policy
When a user follows a link or a page loads certain external resources, the browser may send a Referer request header identifying the page that initiated the request. Depending on the policy and navigation, that information can include a full URL or only the origin.
URLs sometimes contain information that should not be shared unnecessarily, such as search terms, internal document names, or tracking parameters. Applications should avoid placing passwords, session tokens, and other secrets in URLs in the first place, because URLs can appear in logs, browser history, and other systems in addition to referrer information.
A common policy is:
Referrer-Policy: strict-origin-when-cross-origin
With this setting, browsers generally send the full referrer URL for same-origin requests, send only the origin for cross-origin requests over secure connections, and omit the referrer when a request moves from a secure context to a less secure one.
A stricter option is no-referrer, which instructs the browser not to send referrer information. That can improve privacy in some situations, but it may affect analytics or integrations that depend on referral data. Choose a policy based on the site's privacy requirements and expected behavior.
7. Permissions-Policy
Modern browsers provide access to features such as camera, microphone, geolocation, and other device capabilities. Permission prompts and browser security rules already limit access, but websites can further restrict which features are available to their own pages and embedded content.
For a site that does not need camera, microphone, or location access, an example policy is:
Permissions-Policy: camera=(), microphone=(), geolocation=()
The empty allowlists in this example disable the listed features for the document and its embedded frames under the policy. If the website legitimately uses one of these features, the policy must be adjusted to allow the intended origins.
Permissions-Policy is not a replacement for browser permission controls, user consent, or application security. Its supported directives and behavior can vary by browser and feature, so verify the features that matter to your application before deploying a restrictive policy.
8. Other security headers worth understanding
Cross-Origin-Opener-Policy
Cross-Origin-Opener-Policy (COOP) controls certain relationships between a document and browsing contexts opened through mechanisms such as windows and tabs. A policy such as same-origin can isolate a document from cross-origin opener relationships and help reduce some cross-origin interaction risks.
COOP can affect sign-in popups, payment flows, and integrations that rely on communication between windows. Test those features before enforcing a restrictive policy.
Cross-Origin-Resource-Policy
Cross-Origin-Resource-Policy (CORP) lets a resource indicate which types of origins or sites may load it in certain cross-origin contexts. It can help prevent unintended cross-origin use of resources, but an overly restrictive value may interfere with images, scripts, or other assets intentionally used by external sites.
Cross-Origin-Embedder-Policy
Cross-Origin-Embedder-Policy (COEP) can be used with other cross-origin isolation controls to restrict how a document loads cross-origin resources. It is important for particular advanced browser features, but it is not a universal requirement for every website and can require changes to third-party resource handling.
Do not add headers just to collect more of them
Every policy should have a clear purpose. Some headers are useful baselines for many sites, while cross-origin isolation policies and other advanced controls depend on specific application requirements. An unsupported or unnecessarily strict policy can break legitimate functionality without providing a meaningful benefit.
9. How to test and deploy security headers
Before changing the configuration, inspect the actual HTTP responses returned by the public website. A policy may be configured at the application, web server, reverse proxy, content delivery network, or hosting platform, and different layers can produce different results.
Step 1: Inspect the response
Browser developer tools can show response headers in the Network panel. For a public website, a command-line request can also help:
curl -sS -D - -o /dev/null https://example.com/
Replace example.com with your own domain. The command displays response headers for the requested URL. Redirects may lead to additional responses, so inspect the redirect chain as well when checking HTTP-to-HTTPS behavior.
Step 2: Check more than the homepage
Inspect important page types, including login pages, forms, error pages, subdomains, and pages that load third-party resources. A website may return different headers for different routes or content types. Check both the final HTTPS response and relevant redirects.
Step 3: Test changes before enforcing them
Start with policies whose requirements are clear, such as an appropriate referrer policy or X-Content-Type-Options: nosniff. Confirm that the server returns the intended values and that the changes do not interfere with normal site behavior.
For CSP and cross-origin isolation policies, test in a staging environment when possible. Review browser console messages and relevant reports, then make the policy stricter in stages. Keep a way to roll back a change if a critical feature stops working.
Step 4: Use scanners as a starting point
The SecurityHeaders.com service can inspect publicly accessible response headers and identify common omissions. It is useful for an initial review, but its grade is not a complete security assessment. A high score does not prove that a site is free from vulnerabilities, and a missing header does not automatically mean that a specific attack is possible.
For technical details, consult the MDN HTTP headers reference and the MDN Content Security Policy guide. These references explain browser behavior, policy directives, and configuration considerations in greater detail.
What if your website uses Blogger or managed hosting?
Not every site owner controls the web server directly. On a managed platform such as Blogger, the platform controls much of the response infrastructure, so adding arbitrary HTTP response headers may not be possible through the theme editor alone.
Editing HTML or adding JavaScript to a page does not reliably set an HTTP response header. A meta element can support some browser policies, but it cannot replace every response header; for example, HSTS and CSP's frame-ancestors require appropriate HTTP header delivery.
If your hosting platform does not expose header configuration, first check its official documentation and available settings. A reverse proxy or CDN may provide additional control in some setups, but only use one if it is compatible with your platform and configured correctly. Avoid adding infrastructure solely to improve a scanner score without understanding the maintenance and compatibility costs.
Conclusion
HTTP security headers are an important part of browser-facing security because they allow a website to communicate clear rules to the browser. HSTS strengthens HTTPS enforcement, CSP restricts resource loading and certain browser behaviors, and other headers help manage framing, content interpretation, referrer information, and browser features.
The most effective approach is not to copy every available header into a configuration file. Identify the risks relevant to the site, select policies that address those risks, and test them against real application behavior. Some changes are straightforward, while others require careful planning because they can interfere with legitimate resources or integrations.
Security headers work best alongside secure coding, reliable authentication, dependency updates, access controls, and appropriate monitoring. They are a useful layer of defense, not a substitute for fixing vulnerabilities in the application itself.
Key Takeaways
- HTTP security headers let browsers enforce specific policies for website responses.
- HSTS encourages future connections to use HTTPS, but requires careful planning for subdomains and preload.
- CSP can reduce some XSS risks, but should be tested before enforcement.
X-Content-Type-Options: nosniffhelps prevent certain MIME-sniffing problems.- CSP
frame-ancestorsand X-Frame-Options help protect against clickjacking. - Referrer-Policy limits the referrer information sent during navigation and resource requests.
- Permissions-Policy restricts selected browser features where supported.
- Header scanners are useful diagnostic tools, not proof that a website is secure.
- Managed platforms may restrict which headers a site owner can configure directly.