Website security headers explained

Check your current headers first with the free security headers checker. It grades the response from A+ to F and gives copy-paste fixes for Apache, nginx and Cloudflare. Then read about each header below.

Strict-Transport-Security (HSTS)

Tells the browser to use only HTTPS for your site for a set time, even if someone types http:// or clicks an old link. It protects against downgrade attacks on public networks.

A common value: Strict-Transport-Security: max-age=31536000; includeSubDomains. Only add includeSubDomains if every subdomain works over HTTPS. Start with a short max-age (for example one day) while testing, because browsers remember the policy for the full period and you cannot recall it. Preloading (preload) builds the policy into browsers and is hard to undo; treat it as a deliberate, long-term decision.

Content-Security-Policy (CSP)

Lists which sources the page may load scripts, styles, images, frames and other resources from. A strict CSP is the strongest browser-side defence against cross-site scripting and many injected-script attacks, including some card skimmers.

A reasonable starting point for many sites: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self', then add the external sources you really use. Policies that allow 'unsafe-inline' scripts or any https: source give much weaker protection; nonces or hashes are the stronger alternative.

Roll it out with Content-Security-Policy-Report-Only first. The browser reports what would be blocked without blocking it, so you can fix the policy before enforcing it.

X-Content-Type-Options

X-Content-Type-Options: nosniff stops browsers from guessing a file's type. Without it, a file uploaded as an image could be interpreted as a script. There is no reason not to send it on every response.

Clickjacking: X-Frame-Options and frame-ancestors

Clickjacking hides your page in an invisible frame on another site and tricks visitors into clicking buttons on it. X-Frame-Options: DENY (or SAMEORIGIN) stops other sites from framing yours. The modern equivalent is the CSP directive frame-ancestors 'self', which also lets you list specific partners. Sending both is fine and covers older browsers.

Referrer-Policy

Controls how much of the current URL is sent to other sites when visitors follow links or load resources. URLs can contain search terms, reset tokens or order numbers. Referrer-Policy: strict-origin-when-cross-origin sends only your domain to other sites and the full URL within your own site. It is the default in modern browsers, but setting it explicitly protects older ones.

Permissions-Policy

Switches off browser features the site does not use, such as the camera, microphone or geolocation, so an injected script cannot use them either. Example: Permissions-Policy: camera=(), microphone=(), geolocation=().

Cross-origin isolation headers

• Cross-Origin-Opener-Policy: same-origin keeps other windows you open (or that open you) from keeping a reference to your page. Test login popups and payment windows before enabling it.
• Cross-Origin-Resource-Policy: same-origin stops other sites from embedding your resources. Do not set it on files you serve to other sites, such as public images or a CDN.

Headers you can drop

• X-XSS-Protection: the browser filter it controlled has been removed from modern browsers, and the old filter could itself be abused. Omit it, or send 0.
• Server and X-Powered-By with version numbers: they do not protect anything and tell attackers exactly which software version to target. Remove the versions where your server allows it.

Where to add security headers

• Web server: add_header in nginx (use the always parameter so errors get headers too) or Header always set in Apache.
• CDN or proxy: most CDNs can add response headers without touching the server. Webforta Shield can add HSTS and missing security headers at the edge, without overriding headers your origin already sets.
• Application: frameworks and CMS plugins can set them. The Webforta WordPress Security plugin includes a security headers switch.

A sensible starting set

If you are starting from nothing, these headers are safe for almost every site and can be added in one deployment:

• Strict-Transport-Security: max-age=86400 (raise it to a year once you are sure HTTPS works everywhere).
• X-Content-Type-Options: nosniff
• X-Frame-Options: SAMEORIGIN
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy: camera=(), microphone=(), geolocation=()
• Content-Security-Policy-Report-Only with a draft policy, until you are ready to enforce it.

How to test your changes

1. Check the live response with the security headers checker, or curl -I https://example.com from a terminal.
2. Test a page, an image, a redirect and an error page: servers often add headers only to some responses.
3. Click through login, checkout, embedded videos and any payment popups with the browser console open, and look for blocked resources.
4. Re-test after every server, CDN or plugin change.

Keep them from disappearing

Headers often vanish after a server migration, a CDN change or a new deployment. Webforta Monitor compares security headers on every successful check and alerts when one is removed or changed, and Webforta Scan reports missing headers, weak CSP gaps and permissive CORS with the exact fix.