HTTP security headers: what each one does and how to activate them on your server (free generator)

There's a very common false-security trap: “my site has the green padlock (HTTPS), so it's secure.” HTTPS encrypts the path — no one reads the password in transit. But it doesn't tell the browser how to behave inside the page. And by default, the browser does several dangerous things: it lets your site be placed in a scammer's <iframe>, “guesses” file types, runs scripts from anywhere. HTTP security headers are half a dozen lines in your server config that close those doors.

Which HTTP security headers actually matter?

• Strict-Transport-Security (HSTS) — forces the browser to only talk to you over HTTPS, even if someone tries to force HTTP. Only enable it once HTTPS is fully live.
• X-Content-Type-Options: nosniff — stops the browser from “guessing” a file is something else (a .txt becoming a script). Closes a whole class of attacks.
• X-Frame-Options: SAMEORIGIN — forbids your site from being embedded in a third-party iframe. It's the anti-clickjacking header (that invisible-button-over-yours trick).
• Referrer-Policy — controls how much of the current URL leaks in the Referer header when a user clicks away. Avoids leaking internal paths and URL tokens.
• Permissions-Policy — turns off browser APIs your site doesn't use (camera, microphone, geolocation). If a malicious script gets in, it can't ask for your webcam.
• Content-Security-Policy (CSP) — the most powerful against XSS: it says exactly where scripts, images and styles may come from. Anything not on the list, the browser refuses. It's also the fiddliest to tune — hence the golden tip below.

What is the golden rule for implementing CSP?

Locking CSP down all at once breaks sites (images disappear, legit scripts vanish). The right way: ship it first as Content-Security-Policy-Report-Only. In that mode it only reports what would be blocked, without blocking anything. You watch the console/report, tune the policy until it stops complaining about legitimate things, and only then switch to the real Content-Security-Policy.

Where should I configure HTTP security headers?

It depends on your server — and the generator below spits out both, ready to paste:

• Apache (most shared hosting, including Hostinger's default): goes in .htaccess, inside <IfModule mod_headers.c>.
• Nginx: goes in the server { ... } block with add_header ... always;.

After applying, test it: drop your domain into securityheaders.com or the Mozilla Observatory — they give a grade and list what's missing. The grade jumps right away.

Tick the headers you want in the generator just below and grab the ready-to-paste config. 👇

FAQ

Isn't HTTPS enough? No. HTTPS encrypts the path but doesn't tell the browser how to act inside the page — clickjacking, XSS and Referer leaks happen with the padlock on. Headers are the second layer.
Will CSP break my site? It can, if you lock everything at once. Start in Content-Security-Policy-Report-Only (reports only, blocks nothing), tune, then switch to real CSP.
How do I test? Run your domain through securityheaders.com or the Mozilla Observatory — they grade it and list what's missing.

This guide is part of the Website security series. References: MDN — CSP, securityheaders.com, OWASP Secure Headers.