Guide · Security basics

Security headers for an AI-built app, in plain English

Security headers are short lines your server sends with every page. They tell your visitors’ browsers how to protect them: use HTTPS only, run scripts only from places you trust, don’t let other sites frame you. Your app works the same without them, which is why they’re easy to miss. Six cover most of it, and each one is a few lines of setup.

The six, at a glance

None of them fixes a bug in your code. They limit what a mistake, or someone else’s trick, can do to your users.

How do I see my app’s headers?

1. Open your live app and open the developer tools (F12, or right-click › Inspect), then the Network tab.
2. Reload the page and click the first row, the page itself.
3. Under Response Headers, look for the six names above. Any you can’t find aren’t set.

Or let our checker read them for you: each one is a line in the Security basics part of your report.

HTTPS and HSTS: always the secure address

HTTPS keeps what your users see and send private on the way. Two things make sure they always get it. First, every http:// address should redirect permanently to the same https:// one. Second, the Strict-Transport-Security header (HSTS) tells the browser to use only HTTPS for your site for as long as max-age says, so it never tries plain HTTP again (MDN). Browsers ignore the header if it arrives over plain HTTP, and the very first visit can still start on HTTP.

On a .app or .dev address? Those whole endings are on the HSTS preload list, so browsers only ever open them over HTTPS (Google Registry). That list is built into Chrome, and Firefox, Safari and Edge have their own lists based on it (hstspreload.org). Our checker knows this: an app on one of those endings passes both lines with no header needed.

Content Security Policy: which scripts may run

A Content Security Policy (CSP) lists where your page may load scripts and other files from. If someone slips a script into your page, through a comment box or a bad package, the browser refuses to run it unless it comes from a place you listed (MDN). A policy that allows 'unsafe-inline' scripts loses most of that protection, and our checker says so.

You can set a CSP as a header, or in a <meta http-equiv="Content-Security-Policy"> tag in your page if your host doesn’t let you set headers. Our checker counts both. Two parts only work in the header: frame-ancestors, which browsers ignore in a <meta> tag (MDN), and Report-Only mode, which lets you see what a policy would block without blocking it (MDN).

Start in Report-Only, use the app for a while, add anything real it blocks, then switch it on. A strict policy turned on at once can break your own app.

Framing: stop clickjacking

Without a rule, any website can load your app in an invisible frame over its own buttons, so your users click things in your app they never meant to. That’s clickjacking. X-Frame-Options: DENY (or SAMEORIGIN, to allow only your own pages) stops it (MDN). The CSP directive frame-ancestors is the more complete way to say the same thing, but only in a header, not a <meta> tag. The prompt below sets both.

nosniff: no guessing file types

Browsers sometimes guess what a file is from its contents. X-Content-Type-Options: nosniff turns the guessing off, and blocks a script or style whose declared type doesn’t match (MDN). It matters most if people can upload files to your app.

Referrer-Policy: keep page addresses to yourself

When someone clicks a link from your app to another site, the browser can tell that site which page they came from. If your addresses hold anything private, like a reset token or a search, that’s a leak. With no policy set, browsers default to strict-origin-when-cross-origin, which sends other sites only your domain (MDN). Setting it yourself keeps it that way in every browser. Values like unsafe-url send the full address, query string and all, to every site.

A <meta name="referrer"> tag works too, and our checker reads it. If you set both, make sure they say the same thing.

Where do I set headers?

• Vercel: a headers list in vercel.json (Vercel docs).
• Netlify: a _headers file in the folder you publish, or headers in netlify.toml (Netlify docs).
• Cloudflare Pages: a _headers file in your build output folder (Cloudflare docs).
• No header setting at all? The CSP and referrer policy still work as <meta> tags in your page. The others need a header.

Each prompt above asks your AI tool to show you where the setting goes for your host. Paste one at a time, publish, then check again.

What this can’t tell you

We read the headers of the page you check, as any browser receives them. Other pages, your API and files your app downloads can be served with different headers, so it’s worth checking an inner page too. And a header only limits damage: it can’t tell whether your code or your database rules are safe.

Related

• Your secret keys are in your app’s JavaScript
• Is your .env file downloadable?