Skip to content
ProfitTool
Back to all articles
Privacy & Security
2 min read

HTTP Security Headers Explained: HSTS, CSP, X-Frame-Options and More

HTTP security headers are directives your web server sends to browsers to prevent common attacks like XSS, clickjacking and protocol downgrade. Here is what each one does.

ProfitTool Team

Security & Dev

Why Security Headers Matter

Security headers are HTTP response headers that tell the browser how to behave when handling your site's content. Correctly configured headers can prevent or mitigate entire classes of attacks — cross-site scripting (XSS), clickjacking, MIME-type sniffing, and protocol downgrade attacks — without requiring any changes to your application code.

Strict-Transport-Security (HSTS)

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Tells browsers to always connect over HTTPS, never HTTP, for the specified duration. Once a browser has seen this header, it will automatically upgrade HTTP requests to HTTPS for the next max-age seconds — even if the user types http:// manually.

includeSubDomains extends the policy to all subdomains. preload enables inclusion in browser HSTS preload lists, which hard-codes HTTPS enforcement before the first visit.

Content-Security-Policy (CSP)

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-abc123'; img-src *

CSP is the most powerful — and complex — security header. It defines exactly which resources (scripts, styles, images, fonts, frames) the browser is allowed to load. A strict CSP is the most effective mitigation against XSS attacks.

Key directives: default-src, script-src, style-src, img-src, connect-src, frame-src, font-src.

Avoid unsafe-inline and unsafe-eval — they largely defeat the purpose of CSP.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Prevents browsers from MIME-sniffing a response away from the declared content type. Without this, a browser might execute a file served as text/plain if it looks like JavaScript. Simple, zero-risk, add it everywhere.

X-Frame-Options

X-Frame-Options: SAMEORIGIN

Prevents your pages from being embedded in <iframe>, <frame> or <object> elements on other origins — the mechanism used in clickjacking attacks. The modern alternative is Content-Security-Policy: frame-ancestors 'self', which is more flexible.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Controls how much of the referring URL is sent in the Referer header. The recommended value sends the full URL for same-origin requests but only the origin (no path) for cross-origin requests, and nothing when downgrading from HTTPS to HTTP.

Permissions-Policy

Permissions-Policy: geolocation=(), microphone=(), camera=()

Restricts which browser features (geolocation, camera, microphone, payment) are allowed on your page and in embedded iframes. Disabling features you do not use reduces your attack surface.

Quick Implementation

Most web servers and CDNs support setting these headers in configuration:

  • Nginx: add_header directives in server or location blocks
  • Apache: Header set directives in .htaccess or httpd.conf
  • Cloudflare: Transform Rules → Response Header Modification
  • Vercel / Netlify: vercel.json or netlify.toml headers sections

Analyse your current header configuration with our Security Headers Checker.

Tags:#security headers#hsts#csp#x-frame-options#web security

ProfitTool Team

Security & Dev

Written and maintained by the ProfitTool team. Where an article references a ProfitTool utility, the behaviour described is the behaviour of the tool on this site — you can open it and check the output yourself.