Security Headers

The most important security headers are Strict-Transport-Security (HSTS) to enforce HTTPS, Content-Security-Policy (CSP) to prevent XSS attacks, and X-Content-Type-Options to stop MIME sniffing. These headers offer essential baseline protection and should always be enabled.

Here are the most common security headers:

• Strict-Transport-Security: Forces browsers to use HTTPS connections only, preventing downgrade attacks and improving transport security.
• Content-Security-Policy: Controls which sources of scripts, styles, objects, and content are allowed to load in the browser, helping prevent XSS and injection attacks.
• Permissions-Policy: Limits browser features like camera, geolocation, and microphone, preventing misuse by embedded content or third-party scripts.
• Referrer-Policy: Controls how much referrer information is sent with requests, helping protect user privacy and sensitive URL data across different origins and requests.
• X-Content-Type-Options: Prevents MIME type sniffing by browsers, ensuring files are interpreted as intended and reducing the risk of malicious file execution.
• X-XSS-Protection: Legacy header once used for XSS filtering; now deprecated (use Content-Security-Policy instead), but sometimes included for compatibility with older browsers.
• X-Frame-Options: Protects against clickjacking by controlling whether your site can be embedded in iframes on other domains or external websites.

Some newer, more advanced security headers include:

• Cross-Origin-Embedder-Policy: Controls which cross-origin resources can be embedded, requiring explicit permission, enabling stronger isolation. It is often the most problematic, since all resources must explicitly permit cross-origin usage via CORP or CORS headers.
• Cross-Origin-Opener-Policy: Isolates browsing contexts to prevent cross-origin interactions, protecting against attacks like cross-window data leaks and cross-origin interference.
• Cross-Origin-Resource-Policy: Restricts which external origins can load your resources, reducing the risk of data leaks and unauthorized access.

A typical setup for a generic website includes Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy. These headers help enforce HTTPS, prevent script injection attacks, and significantly reduce exposure to common browser-based attacks.

Here is an example of security headers for a website. Make sure to update the Content-Security-Policy to allow loading of resources from trusted CDNs or third-party integrations based on your needs. In this example, only Google Fonts and Cloudflare CDNs are allowed.

Dashboards should use strict Content-Security-Policy rules, Strict-Transport-Security (HSTS), X-Frame-Options DENY, and no-cache headers like Cache-Control: no-store. This prevents sensitive data from being cached and protects against clickjacking and unauthorized embedding.

Here is an example of security headers for a dashboard. Make sure to update the Content-Security-Policy to allow loading of resources from trusted CDNs or third-party integrations based on your needs. In this example, only Google Fonts and Cloudflare CDNs are allowed.

Web APIs should include Strict-Transport-Security (HSTS), X-Content-Type-Options, and a strict Content-Type policy (e.g. responses should use application/json). Adding X-Robots-Tag: noindex helps prevent indexing, while proper CORS headers control access and protect endpoints from misuse.

Here is an example of security headers for an API with no browser rendering. COOP, CORP, and Permissions-Policy are included even though they are not strictly required for a JSON API, as they can still provide additional protection and are often checked by security scanners.

CORS are useful when your API is accessed from web applications or embedded in web pages, allowing you to control which domains can interact with it. Below is an example of a basic CORS configuration. Adjust allowed origins, methods, and headers based on your application requirements.

Here are some useful recommendations to consider:

Avoid using wildcard (*) in production unless the API is fully public, as it may expose your endpoints to unauthorized use from other websites. Additionally, do not use Access-Control-Allow-Origin: * together with credentials, as this is not allowed by browsers and may introduce security risks.

You can test security headers using browser Developer Tools or online scanners. In Chrome or Firefox, open DevTools (F12), go to the Network tab, reload the page, and inspect the response headers.

Alternatively, use the security headers checker tool at the top of this page to quickly analyze your website and identify missing or misconfigured headers. The tool provides a detailed analysis, a security score and grade, and helpful insights to improve your security headers configuration and overall compliance.

You can also get the response headers via command line using curl, example:

Review the output to ensure important headers are correctly set.

You can debug Content-Security-Policy (CSP) and COEP/CORP issues using your browser's Developer Tools (F12) in Chrome or Firefox. Open the Console tab to identify blocked resources and policy violations. These errors usually indicate which directive is preventing a resource from loading.

Common Content-Security-Policy error example:

Common COEP/CORP error example:

To fix these issues, update your security headers (e.g. CSP directives or CORP settings) to explicitly allow trusted sources while keeping your policy as restrictive as possible. For example, if Google Fonts are blocked by CSP, you may need to add https://fonts.googleapis.com to the style-src directive and https://fonts.gstatic.com to the font-src directive so they can load properly.

Cross-Origin-Opener-Policy (COOP), Cross-Origin-Resource-Policy (CORP), and Cross-Origin-Embedder-Policy (COEP) help isolate your application from other origins and enable powerful browser features like SharedArrayBuffer. While not yet widely adopted, they are increasingly important and should be considered for high-security applications, particularly dashboards and admin panels handling sensitive data.

However, they can break functionality if your application depends on third-party resources (e.g. ads, widgets, analytics). COEP is the most likely to break integrations, as it blocks cross-origin resources unless explicitly allowed, making it incompatible with many third-party services (such as Stripe JS, which may require proper Cross-Origin-Resource-Policy or CORS headers). COOP is generally safe and controls window isolation, while CORP has a moderate impact by restricting how resources are shared across origins.

Here is an example configuration for a dashboard that shouldn't create issues:

No, modern browsers have deprecated support for X-XSS-Protection. It is better and recommended to rely on Content-Security-Policy to mitigate XSS risks, as CSP provides more robust protection against script injection attacks. However, since many security scanners still check for this header, you may consider including it for compatibility with legacy tools and older browsers.