• Agents
  • Docs
  • Pricing
  • Blog
Log in
Get started

Security for apps built with AI. Paste a URL, get a report, fix what matters.

Product

  • How it works
  • What we find
  • Pricing
  • Agents
  • MCP Server
  • CLI
  • GitHub Action

Resources

  • Blog
  • Docs
  • FAQ
  • Glossary

Security

  • Supabase Security
  • Next.js Security
  • Lovable Security
  • Cursor Security
  • Bolt Security

Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Policy
  • Imprint
© 2026 Flowpatrol. All rights reserved.
Home/Glossary/Security Headers
CWE-693

HTTP Security Headers (Security Headers)

Missing security headers is a protection mechanism failure classified under CWE-693 (Protection Mechanism Failure). HTTP security headers instruct the browser to enforce security policies — blocking inline scripts, preventing framing, forcing HTTPS, and stopping MIME-type sniffing. Without them, your app relies entirely on its own code to prevent attacks, losing an entire layer of browser-enforced defense.

What is Security Headers?

Every time your server responds to a request, it can include headers that tell the browser how to behave. Content-Security-Policy controls which scripts can run. Strict-Transport-Security forces HTTPS. X-Frame-Options blocks clickjacking. These are free security controls — you just have to turn them on.

When these headers are missing, browsers use their permissive defaults. Inline scripts run freely (XSS becomes easier). Your site can be embedded in iframes on malicious pages (clickjacking). Connections can be downgraded from HTTPS to HTTP (man-in-the-middle attacks). MIME types can be sniffed, turning uploaded files into executable scripts.

Security headers are the seatbelts of web development. Your app might never crash, but you still wear them. They're a defense-in-depth layer that catches the things your application code misses.

How does Security Headers work?

Most frameworks ship with zero security headers by default. Next.js, for example, adds X-Powered-By but none of the headers that actually protect users. You have to configure them yourself.

Here's the difference between a default Next.js config and one with proper security headers:

Vulnerable — no security headers configured
// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  // No headers configured.
  // Response includes only default headers:
  //   X-Powered-By: Next.js  (leaks framework)
  //   No CSP, no HSTS, no X-Frame-Options
};

module.exports = nextConfig;
Fixed — security headers in next.config.js
// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  poweredByHeader: false,
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: "default-src 'self'; script-src 'self'",
          },
          {
            key: 'Strict-Transport-Security',
            value: 'max-age=63072000; includeSubDomains; preload',
          },
          {
            key: 'X-Frame-Options',
            value: 'DENY',
          },
          {
            key: 'X-Content-Type-Options',
            value: 'nosniff',
          },
          {
            key: 'Referrer-Policy',
            value: 'strict-origin-when-cross-origin',
          },
          {
            key: 'Permissions-Policy',
            value: 'camera=(), microphone=(), geolocation=()',
          },
        ],
      },
    ];
  },
};

module.exports = nextConfig;

Why do AI tools generate Security Headers vulnerabilities?

AI code generators build apps that work — and security headers have zero impact on functionality. Nothing looks broken without them. No test fails. No page errors out. So they never get added.

  • Headers are invisible to the app. Security headers affect browser behavior, not application behavior. The AI builds a working app, and a working app doesn't need them to function.
  • CSP is hard to get right. A strict Content-Security-Policy can break inline scripts, third-party widgets, and analytics. AI avoids generating configs that might cause errors.
  • Framework defaults are permissive. Next.js, Express, and most frameworks ship without security headers. The AI follows the framework's conventions — and the conventions skip security.

The result is that virtually every AI-generated app ships without security headers. It's one of the easiest things to fix and one of the most commonly missed.

Common Security Headers patterns

No Content-Security-Policy

Without CSP, any injected script runs freely. This is the single most impactful missing header for XSS prevention.

No Strict-Transport-Security

Without HSTS, first-time visitors and bookmark users can be intercepted via HTTP before the redirect to HTTPS fires.

No X-Frame-Options

Without framing protection, your app can be embedded in an invisible iframe for clickjacking attacks.

X-Powered-By exposed

Headers like X-Powered-By: Next.js or X-Powered-By: Express advertise your stack, helping attackers pick targeted exploits.

How Flowpatrol detects Security Headers

Flowpatrol checks every response your app sends for the security headers that modern browsers expect:

  1. 1Fetches key pages and API endpoints and inspects the full set of response headers on each one.
  2. 2Checks for each critical header — CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
  3. 3Validates header values — a weak CSP with unsafe-inline is almost as bad as no CSP at all.
  4. 4Flags information leaks — X-Powered-By, Server version strings, and other headers that expose your stack.

Security headers take five minutes to add and protect every user on every page load. Flowpatrol tells you exactly which ones you're missing.

Related terms

UI Redressing (Clickjacking)Cross-Site Scripting (XSS)Cross-Origin Resource Sharing (CORS Misconfiguration)

Check your security headers.

Flowpatrol scans your response headers and tells you exactly what's missing. Paste your URL — takes seconds.

Try it free