Docs

Managing HTTP Security Headers

Overview

The WAF can add HTTP security headers to responses served through it. These headers instruct browsers to enforce security policies that help protect your visitors from common attacks. This document explains which headers the WAF manages, how they interact with headers your application sets, and how to handle Content Security Policy (CSP).

WAF-Managed Headers

When enabled, the WAF adds these security headers to responses. See Enabling Security Headers for how to turn them on.

X-XSS-Protection

Instructs browsers to activate their built-in XSS filter, which can block some reflected cross-site scripting attacks.

X-Frame-Options

Prevents your pages from being loaded inside iframes on other sites, protecting against clickjacking attacks.

X-Content-Type-Options

Prevents browsers from MIME-type sniffing, which can be exploited in content injection attacks.

How WAF Headers Interact with Application Headers

If your application also sets security headers, the WAF’s behavior depends on which header it is:

  • WAF headers are added when your application does not set the same header. The WAF fills in the gap.
  • Application headers take precedence when both the WAF and your application set the same header. The WAF does not overwrite your application’s value.

This means you can safely enable WAF security headers as a baseline while setting more specific values in your application where needed.

Content Security Policy (CSP)

The WAF does not set a Content Security Policy header. CSP is highly application-specific — it depends on which scripts, styles, fonts, images, and other resources your application loads — so it must be configured in your application.

Setting CSP in Your Application

Add a Content-Security-Policy header in your application’s responses. Most web frameworks provide middleware or configuration for this:

  • Rails: Use the content_security_policy configuration in an initializer
  • Express/Node: Use the helmet middleware with CSP options
  • Django: Use the django-csp package

CSP and the WAF

The WAF passes your application’s CSP header through to visitors without modification. There are no conflicts between the WAF and application-level CSP headers.

However, if your CSP is very restrictive, be aware that:

  • The WAF block page (shown when a request is blocked) uses its own inline styles and scripts. These will not be affected by your CSP because the block page is served directly by the WAF, not by your application.
  • If you use report-uri or report-to directives, CSP violation reports from visitors’ browsers will be sent to whatever endpoint you configure. These requests pass through the WAF like any other request — ensure the reporting endpoint is not blocked by WAF rules.

Other Security Headers

These headers are not managed by the WAF but are commonly set at the application level:

Header Purpose
Strict-Transport-Security (HSTS) Tells browsers to always use HTTPS for your domain. Consider enabling this after confirming HTTPS works correctly.
Referrer-Policy Controls how much referrer information is sent with requests.
Permissions-Policy Controls which browser features (camera, microphone, geolocation) your site can use.

These headers should be set in your application’s responses. The WAF will pass them through to visitors without modification.

Need Help?

If you have questions about security headers or how the WAF interacts with your application’s headers: