HTTP Security Headers Every Website Should Have

Emil Gheonea

Software engineer & founder of LinkThreatScan · 10 March 2026

HTTP response headers are metadata that a web server sends back to the browser along with a page's content. Most are invisible to users, but they carry important instructions about how the browser should behave. Security headers are a specific subset that tell the browser to apply protective policies — blocking certain attack vectors without requiring any changes to the application code itself.

Content-Security-Policy (CSP)

CSP is the most powerful security header. It defines a whitelist of sources from which the browser is allowed to load scripts, styles, images, fonts, and other resources. A well-configured CSP prevents Cross-Site Scripting (XSS) attacks by ensuring that even if an attacker injects a malicious script tag, the browser will refuse to execute it because the source isn't whitelisted. Example: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;

Strict-Transport-Security (HSTS)

HSTS instructs the browser to only communicate with the site over HTTPS — never plain HTTP — for a specified duration. Once a browser receives this header, it will automatically upgrade all future requests to the site to HTTPS, even if the user types 'http://' or clicks an HTTP link. This prevents SSL stripping attacks. The includeSubDomains directive extends protection to all subdomains; the preload directive allows the site to be hardcoded into browsers' HSTS preload lists.

X-Frame-Options and Content-Security-Policy frame-ancestors

These headers prevent your site's content from being embedded inside an iframe on another domain. Without them, attackers can overlay your site with a transparent layer that captures clicks intended for your interface — a technique called clickjacking. X-Frame-Options: DENY or SAMEORIGIN is the older approach; the CSP frame-ancestors directive is more flexible and recommended in modern configurations.

X-Content-Type-Options

Setting this header to 'nosniff' prevents browsers from trying to guess (sniff) the content type of a response. Without it, a browser might execute a file served as text/plain as a script if it looks like JavaScript. This closes off a category of MIME confusion attacks. Configuration: X-Content-Type-Options: nosniff

Referrer-Policy

This header controls how much information about the originating page is included in the Referer header when a user navigates away from your site. Without it, the full URL (potentially including authentication tokens or sensitive query parameters) is sent to third-party sites in referrer headers. Recommended: Referrer-Policy: strict-origin-when-cross-origin.

Permissions-Policy

Formerly called Feature-Policy, this header lets you restrict which browser features and APIs are available to the page — for example, disabling camera access, microphone, geolocation, or payment APIs if your site doesn't use them. This limits the damage an XSS attack can cause by reducing the APIs available to injected code.

How to check your headers

Paste your URL into LinkThreatScan and we'll inspect every security header in your response, flag which ones are missing or misconfigured, and explain what each one protects against. Adding these headers typically takes less than an hour in a web server or CDN configuration and significantly improves your site's security posture.