Advanced HTTP Security Headers: A Deep Dive

You've already implemented the basics like HSTS and X-Frame-Options. Now it's time to take your web security to the next level. Advanced HTTP security headers provide granular control over browser features, resource loading, and cross-origin policies, offering a robust defense against modern web threats like cross-site scripting (XSS), data injection, and side-channel attacks.

1. Content-Security-Policy (CSP)

CSP is arguably the most powerful security header. It allows you to create a whitelist of sources from which the browser is allowed to load resources (like scripts, styles, images, etc.). A well-configured CSP can effectively eliminate most XSS vulnerabilities.

Example: A Strict CSP

This policy only allows resources from the same origin and explicitly trusted sources.

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted-analytics.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; base-uri 'self';" always;

• default-src 'self': By default, only allow resources from your own domain.
• script-src 'self' https://trusted-analytics.com: Allow scripts from your domain and from `trusted-analytics.com`.
• style-src 'self' 'unsafe-inline': Allow stylesheets from your domain and inline styles. (Avoid 'unsafe-inline' if possible!).
• object-src 'none': Disallow plugins like Flash.
• frame-ancestors 'none': Prevents your site from being iframed (similar to X-Frame-Options).

Pro-Tip: Start with a Content-Security-Policy-Report-Only header to test your policy without breaking your site. This will send violation reports to a specified endpoint, allowing you to refine your directives.

2. Permissions-Policy (formerly Feature-Policy)

This header allows you to control which browser features (like camera, microphone, geolocation, fullscreen) can be used on your site and in any embedded iframes. It's essential for privacy and for preventing third-party content from abusing powerful APIs.

Example: A Restrictive Permissions-Policy

This policy disables several potentially sensitive features by default.

add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), fullscreen=(self)" always;

This example completely disables the camera, microphone, geolocation, Payment Request API, and WebUSB API. It only allows the Fullscreen API to be used by your own top-level page, not by iframes.

3. Cross-Origin Policies (COOP, COEP, CORP)

These headers are designed to mitigate speculative execution side-channel attacks like Spectre. They work together to enable a special state called "cross-origin isolation," which provides a separate process for your website in the browser, enhancing security.

add_header Cross-Origin-Opener-Policy "same-origin-allow-popups" always;

add_header Cross-Origin-Embedder-Policy "require-corp" always;

# Set on a resource (e.g., an image) you are serving
add_header Cross-Origin-Resource-Policy "same-origin" always;

Important: Enabling COEP can be complex, as it requires all cross-origin resources you use to have the appropriate CORP header. This may not be possible for some third-party services.

4. Referrer-Policy

Controls how much referrer information (the URL of the previous page) is sent with requests. This is crucial for privacy, as URLs can contain sensitive information.

Example: A Privacy-Focused Referrer-Policy

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

This is a good default. It sends the full URL for same-origin requests but only sends the origin (e.g., `https://your-site.com`) for cross-origin requests. It sends no referrer at all when downgrading from HTTPS to HTTP.