Security headers are HTTP response headers that instruct a browser on how to handle your website securely. They operate silently in the background and help reduce risks such as insecure connections, script injection, clickjacking, and unintended data exposure. When configured, this allows consistent enforcement across environments.
Strict-Transport-Security ensures that a browser connects to your website using HTTPS only.
When a user visits your site over HTTPS and receives this header, the browser remembers the rule for the duration defined in max-age. In this example, 31536000 seconds equals one year.
before sending the request. If includeSubDomains is present, the same rule applies to all subdomains.
This header is commonly used to prevent downgrade attacks and to make sure encrypted communication is always enforced. It is especially important for login pages, APIs, dashboards, and applications handling sensitive information.
Content-Security-Policy controls which sources the browser is allowed to load content from.
In this configuration, the browser loads resources only from the same domain unless explicitly allowed. Scripts are restricted to your own site. Images may load from your domain and from a trusted CDN. Plugins such as Flash are blocked entirely.
the browser blocks it because it does not match the approved sources.
CSP is widely used to reduce the risk of Cross Site Scripting and unauthorized content injection. It significantly limits what an attacker can execute inside a compromised page. When using third party services, those domains must be explicitly permitted in the policy.
This header prevents browsers from guessing file types.
but actually contains JavaScript, the browser will not attempt to execute it.
This header is commonly used to reduce the risk of file upload abuse and accidental execution of improperly labeled files.
X-Frame-Options controls whether your site can be displayed inside an iframe.
the browser blocks it.
This allows embedding only if the parent page belongs to the same domain.
This header is typically enabled to prevent clickjacking attacks, where users are tricked into interacting with hidden elements layered over a legitimate page.
Referrer-Policy determines how much information is sent in the Referer header when users navigate away from your site.
The full URL including parameters is not shared.
This helps prevent sensitive query parameters from being exposed to external sites while still preserving useful referral data for analytics.
Modern browsers rely on Content-Security-Policy for XSS protection. Setting this value to 0 disables older filtering mechanisms that may behave inconsistently.
It is typically configured to avoid relying on deprecated browser features.
Permissions-Policy controls access to browser features and APIs.
In this configuration, camera, microphone, and geolocation access are disabled entirely. The Payment API is restricted to the same origin.
If a script attempts to use a blocked feature, the browser denies the request.
This header is used to reduce unnecessary browser capability exposure and to limit access to sensitive device features.
Cross-Origin Isolation headers control how your website interacts with resources from other domains. When enabled, they create a stricter security boundary inside the browser, limiting how cross-origin content is loaded and shared.
When these headers are enabled:
• The browser isolates your website from other origins
• Cross-origin resources must explicitly allow being embedded
• Unapproved third-party resources are blocked automatically
For example, if your site loads a script from a third-party CDN and that CDN does not send compatible cross-origin headers, the browser will block the script from loading.
This prevents unintended data sharing between websites and strengthens protection against certain browser-level attacks.
These headers are typically required only for advanced use cases such as:
• Applications using SharedArrayBuffer
• High-performance WebAssembly workloads
• Security-sensitive environments requiring stronger browser isolation
For standard websites, dashboards, or APIs, cross-origin isolation is generally not required.
Cache-Control determines how responses are stored and reused.
With this configuration, the response is not stored permanently. The browser must validate it with the server before reuse, and shared proxies cannot cache it.
If a user logs out and presses the back button, the browser must request a fresh copy rather than displaying cached sensitive data.
This setting is commonly applied to login pages, financial dashboards, and other areas containing private information. It should not be applied to static assets such as images or stylesheets, as it negatively affects performance.
Security headers should be deployed in a controlled and tested manner. While they improve browser-level protection, overly strict configurations can introduce outages or integration failures.