🚀Announcing Flightcontrol - Optimized Deployment for Fullstack Blitz.js and Next.js 🚀
Back to Documentation Menu

Security Headers


Jump to a Topic

To improve the security of your application, you can use headers in blitz.config.js to apply HTTP response headers to all routes in your application.

// blitz.config.js

// You can choose which headers to add to the list
// after learning more below.
const securityHeaders = []

module.exports = {
  async headers() {
    return [
        // Apply these headers to all routes in your application.
        source: "/(.*)",
        headers: securityHeaders,



This header controls DNS prefetching, allowing browsers to proactively perform domain name resolution on external links, images, CSS, JavaScript, and more. This prefetching is performed in the background, so the DNS is more likely to be resolved by the time the referenced items are needed. This reduces latency when the user clicks a link.

  key: 'X-DNS-Prefetch-Control',
  value: 'on'

X-DNS-Prefetch-Control documentation


This header informs browsers it should only be accessed using HTTPS, instead of using HTTP. Using the configuration below, all present and future subdomains will use HTTPS for a max-age of 2 years. This blocks access to pages or subdomains that can only be served over HTTP.

If you're deploying to Vercel, this header is not necessary as it's automatically added to all deployments.

  key: 'Strict-Transport-Security',
  value: 'max-age=31536000; includeSubDomains; preload'

Strict-Transport-Security documentation


This header stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Although this protection is not necessary when sites implement a strong Content-Security-Policy disabling the use of inline JavaScript ('unsafe-inline'), it can still provide protection for older web browsers that don't support CSP.

  key: 'X-XSS-Protection',
  value: '1; mode=block'

X-XSS-Protection documentation


This header indicates whether the site should be allowed to be displayed within an iframe. This can prevent against clickjacking attacks. This header has been superseded by CSP's frame-ancestors option, which has better support in modern browsers.

  key: 'X-Frame-Options',
  value: 'SAMEORIGIN'

X-Frame-Options documentation


This header allows you to control which features and APIs can be used in the browser. It was previously named Feature-Policy. You can view the full list of permission options here.

  key: 'Permissions-Policy',
  value: 'camera=(), microphone=(), geolocation=(), interest-cohort=()'

Permissions-Policy documentation


This header prevents the browser from attempting to guess the type of content if the Content-Type header is not explicitly set. This can prevent XSS exploits for websites that allow users to upload and share files. For example, a user trying to download an image, but having it treated as a different Content-Type like an executable, which could be malicious. This header also applies to downloading browser extensions. The only valid value for this header is nosniff.

  key: 'X-Content-Type-Options',
  value: 'nosniff'

X-Content-Type-Options documentation


This header controls how much information the browser includes when navigating from the current website (origin) to another. You can read about the different options here.

  key: 'Referrer-Policy',
  value: 'origin-when-cross-origin'

Referrer-Policy documentation


This header helps prevent cross-site scripting (XSS), clickjacking and other code injection attacks. Content Security Policy (CSP) can specify allowed origins for content including scripts, stylesheets, images, fonts, objects, media (audio, video), iframes, and more.

You can read about the many different CSP options here.

  key: 'Content-Security-Policy',
  value: // Your CSP Policy

Content-Security-Policy documentation


Idea for improving this page? Edit it on GitHub.