What security headers actually do

When your browser loads a web page, the server sends back not just the HTML content, but also a set of HTTP response headers — metadata that tells the browser how to handle the response. Some of these headers are for performance and caching. Security headers are a specific group that give the browser instructions about security-related behaviour.

Think of them as rules you set for your visitors' browsers. You can tell the browser: "Never load this site over plain HTTP," "Do not let this page be embedded in another site's iframe," "Do not execute inline scripts unless they come from this specific list of sources." Browsers follow these rules, and following them blocks a range of attacks that would otherwise be possible.

The key point is that these headers are not primarily there to prevent server-side attacks. They sit in the browser layer and help protect against attacks like cross-site scripting, clickjacking, and protocol downgrade attacks — attacks that try to use the browser itself as a vector.

The most important security headers

Strict-Transport-Security (HSTS)

This header tells the browser that your site should always be loaded over HTTPS, and never over plain HTTP. Once a browser sees this header, it remembers the rule for the duration you specify (the max-age value, in seconds) and will refuse to connect to your site over HTTP for that entire period — even if the user types in an HTTP address directly.

This prevents a class of attack called an SSL stripping attack, where an attacker on the same network intercepts the initial HTTP request before it redirects to HTTPS, keeping the connection unencrypted throughout the session.

          # Add to your server response headers:

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

The max-age of 31536000 is one year in seconds. includeSubDomains applies the rule to all subdomains of your domain as well.

Content-Security-Policy (CSP)

This is the most powerful and flexible security header. It lets you specify exactly which sources of content — scripts, stylesheets, images, fonts, frames — the browser is allowed to load on your page. Anything not on the approved list is blocked.

The main benefit is XSS protection. If an attacker manages to inject a script into your page, a properly configured CSP will prevent that script from loading or executing — because it comes from an untrusted source. A strict CSP is one of the most effective defences against cross-site scripting.

          # A strict policy that only allows content from your own domain:

          Content-Security-Policy: default-src 'self'; img-src 'self' data:; font-src 'self'

          # A more permissive policy that also allows Google Fonts and Analytics:

          Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com

CSP requires careful configuration to avoid breaking your site. Start with a report-only mode (using the Content-Security-Policy-Report-Only header) to see what would be blocked before enforcing it.

X-Frame-Options

This header prevents your website from being embedded inside an iframe on another website. The attack it protects against is called clickjacking — where an attacker overlays a transparent iframe of your site on top of their own malicious page. Visitors think they are clicking on the attacker's page, but they are actually clicking on hidden buttons and links on your site underneath.

Common examples of clickjacking damage include tricking users into clicking "confirm payment," "change email," or "share this post" without realising it.

          # Completely disallow framing:

          X-Frame-Options: DENY

          # Only allow framing from the same origin:

          X-Frame-Options: SAMEORIGIN

X-Content-Type-Options

This header prevents browsers from guessing the content type of a response (MIME type sniffing). Without it, older browsers might interpret a text file as a JavaScript file and execute it — a behaviour that can be exploited to run malicious code uploaded as an innocuous file type.

X-Content-Type-Options: nosniff

This is one of the simplest headers to add — just one line — and it has no downsides for a properly configured website.

Referrer-Policy

When a user clicks a link on your site and goes to another website, browsers by default send the URL of the page they came from in an HTTP header called the Referer. This can expose sensitive information — for example, if your URL contains a password reset token, a session ID, or personal details, that information could be sent to third-party sites.

          # Only send the origin (no path or query string) to other sites:

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

Permissions-Policy

This header controls which browser features and APIs your page can access — and whether third-party content embedded on your page can access them. For example, you can use it to prevent embedded scripts from activating the user's camera or microphone, accessing their location, or using the payment API.

          # Disable camera, microphone, and geolocation for all content including iframes:

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

How to add security headers

How you add security headers depends on how your website is hosted and what technology it runs on. Here are the most common approaches:

Apache (.htaccess)

        # Add to your .htaccess file:

        <IfModule mod_headers.c>

          Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

          Header always set X-Frame-Options "SAMEORIGIN"

          Header always set X-Content-Type-Options "nosniff"

          Header always set Referrer-Policy "strict-origin-when-cross-origin"

        </IfModule>

Nginx (nginx.conf)

        # Add inside your server block:

        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

        add_header X-Frame-Options "SAMEORIGIN";

        add_header X-Content-Type-Options "nosniff";

        add_header Referrer-Policy "strict-origin-when-cross-origin";

WordPress (via a plugin)

If you run WordPress and do not have direct server access, a security plugin like Wordfence, iThemes Security, or Headers & Security can add most of these headers for you through the WordPress admin panel without any server configuration.

Check which headers your site is missing

ScanexAI automatically checks your website for missing or misconfigured security headers as part of its full vulnerability scan. It flags missing Content-Security-Policy, HSTS, X-Frame-Options, and other headers with clear remediation steps. Run a free scan to see your header configuration.

Summary

HTTP security headers are one of the simplest and most effective security improvements you can make to any website. They are free, they take a few minutes to add, and they passively protect against XSS, clickjacking, SSL stripping, MIME sniffing, and other browser-level attacks without any ongoing maintenance.

The most impactful headers to start with are HSTS (force HTTPS), X-Frame-Options (prevent clickjacking), X-Content-Type-Options (prevent MIME sniffing), and Content-Security-Policy (restrict resource loading). Together, they significantly reduce your browser-layer attack surface.

HTTP Security Headers Explained