Security headers: what each HTTP header does and how to set it

What are security headers?

Security headers are HTTP response headers that your server or host sends and the visitor's browser enforces. They decide which scripts may run, whether the browser uses HTTPS only, whether another site may frame your page, and how much of the address goes to other sites. Without them, the browser's default for scripts and framing is to allow everything.

App builders leave this to you. Next.js sends X-Powered-By out of the box and leaves the protective headers to your config, and the hosting built into Lovable and Bolt documents no setting for response headers. The short list that matters today:

OWASP notes that frame-ancestors obsoletes X-Frame-Options in browsers that support it; send both, with matching values, for older browsers. Also remove X-Powered-By and version numbers in Server, as OWASP recommends, and set Secure, HttpOnly and SameSite on session cookies in the code that creates them. One small extra, Cross-Origin-Opener-Policy: same-origin-allow-popups, stops windows on other sites from keeping a handle on yours while your own pop-ups keep working; the checker gives it 2 points of 100.

Which security headers are obsolete?

Old checklists and some scanners still ask for headers that browsers have dropped or replaced. Remove them:

A scanner that flags a missing X-XSS-Protection runs on old rules. The security headers checker does not grade it.

How to test security headers on your own app

1. 1

   Run the free checker

   Paste your address into the security headers checker. It grades the headers from A+ to F, writes the line to add for your host, and also checks the HTTPS redirect, session cookie flags and CORS.

2. 2

   Read the raw headers with curl

   curl -I is the quick version, but it sends a HEAD request. The commands below send a GET, like a browser, and print only the status and headers.

3. 3

   Look in the browser

   In DevTools, open the Network tab, reload, click the first request and read Response Headers: what your browser got after every redirect and CDN.

4. 4

   Check more than the home page

   API routes, error pages and signed-in pages can come from another part of the stack, with other headers. Test one of each.

# Your own app only. Replace the address.
curl -s -D - -o /dev/null https://your-app.com
curl -s -D - -o /dev/null https://your-app.com/api/health
curl -s -D - -o /dev/null https://your-app.com/this-page-does-not-exist
curl -s -D - -o /dev/null http://your-app.com   # expect a 301 or 308 to https://

How to set security headers on each host

Set headers in one place, as close to the edge as you can. Each block sends the five fixed headers; the static-host blocks add a first CSP for framing, plugins and base URLs only, which rarely breaks anything. The script policy comes in the next section.

Next.js: headers() in next.config

Fixed headers go in headers() in next.config.ts (or next.config.js). They apply to every path that matches source, and /:path* matches your /api routes too. The Next.js security guide covers the rest of a Next.js app.

// next.config.ts
import type { NextConfig } from 'next'

const securityHeaders = [
  { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
]

const nextConfig: NextConfig = {
  poweredByHeader: false,
  async headers() {
    return [{ source: '/:path*', headers: securityHeaders }]
  },
}

export default nextConfig

Next.js: the CSP nonce in proxy.ts or middleware.ts

A nonce is a random value, new on every request, that marks your own scripts as allowed. Your proxy puts it in the Content-Security-Policy request header, and Next.js adds it to its framework scripts and bundles. Next.js 16 renamed middleware to proxy (proxy.ts, function proxy) and deprecated the old name; on 15 and earlier, use middleware.ts and a function named middleware.

The cost: pages that use a nonce render on each request. The Next.js docs say static optimization and ISR are disabled, CDN caching needs extra configuration, and Partial Prerendering does not work. The alternatives are the docs' experimental Subresource Integrity mode for the App Router, which keeps pages static, or a weaker CSP with 'unsafe-inline' in script-src.

Vercel without Next.js: vercel.json

For a Vite app or any static site on Vercel, the same pairs go in the headers array of vercel.json at the root of the project. /(.*) matches every path.

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Strict-Transport-Security", "value": "max-age=63072000; includeSubDomains" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" },
        { "key": "Content-Security-Policy", "value": "frame-ancestors 'none'; base-uri 'self'; object-src 'none'" }
      ]
    }
  ]
}

Netlify and Cloudflare Pages: _headers

Netlify reads a plain _headers file from the publish directory, and Cloudflare Pages from the build output: in a Vite app, put it in public/ and the build copies it. On Netlify, a [[headers]] table in netlify.toml does the same job; pick one.

/*
  Strict-Transport-Security: max-age=63072000; includeSubDomains
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  Content-Security-Policy: frame-ancestors 'none'; base-uri 'self'; object-src 'none'

[[headers]]
  for = "/*"
  [headers.values]
    Strict-Transport-Security = "max-age=63072000; includeSubDomains"
    X-Content-Type-Options = "nosniff"
    X-Frame-Options = "DENY"
    Referrer-Policy = "strict-origin-when-cross-origin"
    Permissions-Policy = "camera=(), microphone=(), geolocation=()"
    Content-Security-Policy = "frame-ancestors 'none'; base-uri 'self'; object-src 'none'"

Both hosts' docs set a limit: these headers apply to static files only, not to responses from functions, edge functions or server-rendered pages, which must set their own.

Cloudflare: response header transform rules

When your domain runs through Cloudflare's proxy (the orange cloud in the DNS settings), Cloudflare can add headers to every response, whatever sits behind it: the fix for hosts with no header setting.

1. 1

   Open the rules

   In the dashboard, open your domain, go to Rules > Overview and select Create rule > Response Header Transform Rule.

2. 2

   Match your app

   Match your app's hostname, such as app.example.com, or all incoming requests.

3. 3

   Add one Set static operation per header

   Set static writes your value and replaces any header of the same name. Add the six lines of the _headers file above.

4. 4

   Deploy, then test

   Run the curl commands again. These rules also apply to Cloudflare's own error pages.

Cloudflare does not let you change a few headers, such as server, or any header whose name starts with cf- or x-cf-.

Lovable and Bolt hosting

Neither Lovable's nor Bolt's hosting docs describe a setting for response headers. Run the curl commands on your published app to see what it already sends, then cover the gaps:

• Lovable: its custom domain docs support running behind your own proxy, such as Cloudflare. Connect the domain with Advanced > Uses Cloudflare or similar proxy enabled, then add the Cloudflare rule above. Custom domains need a paid plan, so a lovable.app address cannot do this.
• Bolt: a project that runs entirely in the browser can publish to Netlify through Bolt's integration and use the _headers file above. Bolt says projects that need a backend or its built-in database should stay on Bolt hosting. For those, the remaining route is a proxy you control in front of the custom domain, which Bolt does not document, so test it on a spare domain first.
• Either one, as a stopgap: a CSP meta tag in index.html restricts scripts and connections without touching the host, but it cannot carry frame-ancestors or report-only mode, so test every flow before publishing.

A Content-Security-Policy for Supabase, Stripe and analytics

A CSP lists directives, each naming the allowed sources for one kind of resource: script-src for scripts, connect-src for fetch calls and WebSockets, frame-src for iframes, img-src for images. Start from default-src 'self' (your own origin only) and add each service from its own docs:

Next.js, with a nonce

// proxy.ts on Next.js 16. On Next.js 15 or earlier: middleware.ts, with the function named middleware.
import { NextRequest, NextResponse } from 'next/server'

const SUPABASE = 'YOUR_PROJECT_REF.supabase.co'

export function proxy(request: NextRequest) {
  const nonce = Buffer.from(crypto.randomUUID()).toString('base64')
  const isDev = process.env.NODE_ENV === 'development'
  const csp = `
    default-src 'self';
    script-src 'self' 'nonce-${nonce}' 'strict-dynamic' https://js.stripe.com https://*.js.stripe.com https://maps.googleapis.com https://www.googletagmanager.com${isDev ? " 'unsafe-eval'" : ''};
    style-src 'self' ${isDev ? "'unsafe-inline'" : `'nonce-${nonce}'`};
    img-src 'self' blob: data: https://${SUPABASE} https://www.googletagmanager.com https://*.google-analytics.com;
    font-src 'self';
    connect-src 'self' https://${SUPABASE} wss://${SUPABASE} https://api.stripe.com https://maps.googleapis.com https://www.googletagmanager.com https://*.google-analytics.com https://*.google.com;
    frame-src https://js.stripe.com https://*.js.stripe.com https://hooks.stripe.com;
    object-src 'none';
    base-uri 'self';
    form-action 'self';
    frame-ancestors 'none';
    upgrade-insecure-requests;
  `.replace(/\s{2,}/g, ' ').trim()

  const requestHeaders = new Headers(request.headers)
  requestHeaders.set('x-nonce', nonce)
  // Next.js reads the nonce from this request header (it also accepts a
  // Content-Security-Policy-Report-Only request header) and adds it to its own scripts.
  requestHeaders.set('Content-Security-Policy', csp)

  const response = NextResponse.next({ request: { headers: requestHeaders } })
  // Report-Only first. Once the reports are clean, rename this response header to
  // Content-Security-Policy. The request header above keeps its name either way.
  response.headers.set('Content-Security-Policy-Report-Only', csp)
  return response
}

export const config = {
  matcher: [
    {
      source: '/((?!api|_next/static|_next/image|favicon.ico).*)',
      missing: [
        { type: 'header', key: 'next-router-prefetch' },
        { type: 'header', key: 'purpose', value: 'prefetch' },
      ],
    },
  ],
}

With 'strict-dynamic', current browsers ignore host names in script-src, MDN explains, and trust only scripts that carry the nonce or that such a script loads; the hosts are a fallback for older browsers. Pass the nonce to every Script tag you write. As in the Next.js docs, 'unsafe-eval' and inline styles are allowed only in development, and the matcher skips /api, static files and prefetches.

Static hosts, without a nonce

Vercel, Netlify and Cloudflare Pages serve a Vite build as plain files, so nothing creates a nonce per request. Scripts from files on your domain are covered by 'self'. Check the page source of your published app: each inline script, such as the configuration snippet of Google's tag, must move into a file in your bundle or be allowed by its SHA-256 hash.

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://js.stripe.com https://*.js.stripe.com https://maps.googleapis.com https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https://YOUR_PROJECT_REF.supabase.co https://www.googletagmanager.com https://*.google-analytics.com; connect-src 'self' https://YOUR_PROJECT_REF.supabase.co wss://YOUR_PROJECT_REF.supabase.co https://api.stripe.com https://maps.googleapis.com https://www.googletagmanager.com https://*.google-analytics.com https://*.google.com; frame-src https://js.stripe.com https://*.js.stripe.com https://hooks.stripe.com; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests

Roll it out in Report-Only

1. 1

   Send it as Report-Only

   Use the header name Content-Security-Policy-Report-Only: the browser blocks nothing and reports what it would block, so the checker scores it as blocking nothing yet. upgrade-insecure-requests has no effect in this mode (W3C spec), and X-Frame-Options: DENY keeps framing blocked meanwhile.

2. 2

   Use the app for real

   Sign up, sign in, upload a file, pay in Stripe test mode, open a realtime screen. Each violation shows in the console with the directive and the blocked address. To collect reports from visitors, add a report-to endpoint, which MDN prefers, with report-uri as a fallback.

3. 3

   Fix the policy, not the app

   Add each missing source to the right directive. If you do not recognise an address, find out what loaded it before you allow it.

4. 4

   Enforce

   When a few days of use bring no unexpected report, rename the header to Content-Security-Policy. MDN says browsers honor both headers at once, enforcing one and reporting on the other, so a stricter Report-Only policy can test your next change.

The traps after the obvious fix

Meta tags do less than headers

MDN lists frame-ancestors as unsupported in a CSP meta tag and says a report-only policy cannot be delivered that way; X-Frame-Options in a meta tag has no effect at all. Use real headers wherever the host allows.

HSTS preload is hard to undo

'unsafe-inline' in script-src

MDN says 'unsafe-inline' defeats much of the purpose of a CSP: an injected inline script runs just like yours. Next.js without a nonce needs it for its own inline scripts. Browsers ignore 'unsafe-inline' in a directive that holds a nonce or a hash, so the nonce closes the hole. The checker counts 'unsafe-inline' in script-src as weak.

API routes, functions and error pages

The proxy matcher skips /api, which is fine for JSON, so keep HSTS and nosniff in next.config, which covers every path. _headers files skip functions and server-rendered pages, and your Supabase project is a separate origin whose headers you do not control. Run the curl lines on an API route and a 404 page.

What security headers do not fix

Headers are instructions to a browser. A stranger who calls your API with curl never reads them. They limit what an injected script or a hostile page can do to your visitors, and do nothing about the leaks we find most often in generated apps:

• A table with row level security off. Anyone holding your public Supabase key reads it through the REST API, whatever your CSP says. CVE-2025-48757 was assigned after a researcher found 170 of 1,645 Lovable apps tested with missing or weak RLS. See the Supabase RLS guide.
• A secret key in your JavaScript. A CSP controls what your page loads, not what it ships. See API keys exposed in the frontend.
• A `.env` file served to anyone. See the guide to exposed .env files.
• An AI endpoint anyone can call. See unprotected AI endpoints.
• Another user's records behind a guessable ID. That is an IDOR, and it lives in your code.

Keybrum rates missing headers for what they are: its header check reports a missing HSTS as medium and three or more other missing headers as low, never as a way past sign-in. Another attack checks whether other sites can frame your admin, account and checkout pages. Both run alongside more than 100 attacks on the data itself. For the rest of a pre-launch audit, see the vibe coding security checklist.