HTTP Security Headers Explained

What are HTTP security headers?

HTTP security headers are fields sent with an HTTP response. A browser reads them before or while it loads the page. Some headers affect transport security, some affect where resources can load from, and some affect how the page interacts with other origins. Because they are sent with the response, they are often configured in application middleware, a CDN, a reverse proxy, a load balancer, or a web server.

The important detail is that browsers act on the final response they receive. A header configured at the origin can disappear if a CDN, edge function, redirect, or framework route replaces the response. That is why a security header check should inspect the public HTTPS URL users actually visit, not only a local server configuration file.

Why security headers matter

Security headers matter because they turn browser features into guardrails. A strong Content-Security-Policy can make cross-site scripting harder to exploit. HSTS can prevent accidental insecure HTTP access. X-Frame-Options can stop simple clickjacking attempts. Referrer-Policy can reduce data leakage to third-party sites.

These protections are especially useful for login pages, dashboards, checkout flows, account settings, documentation portals, and SaaS applications. Even simple marketing sites benefit from baseline headers because the cost of adding them is usually low once the site is served reliably over HTTPS.

Strict-Transport-Security

Strict-Transport-Security, often shortened to HSTS, tells browsers to use HTTPS for future requests to a hostname. After a browser sees the header, it remembers that the site should be loaded over HTTPS until the max-age expires. That helps prevent downgrade attacks and avoids accidental insecure links.

A production HSTS policy should use a meaningful max-age. Website Certs treats max-age values below 15552000 seconds as weak because they provide a shorter memory window. Be careful with includeSubDomains and preload. Those options are powerful, but every covered subdomain must be ready to serve HTTPS correctly.

Content-Security-Policy

Content-Security-Policy, or CSP, is one of the most powerful security headers. It tells the browser which sources are allowed for scripts, styles, images, frames, fonts, and other resources. A carefully written CSP can reduce the damage caused by injected script because the browser refuses to load or execute resources outside the allowed policy.

CSP also takes planning. Many existing sites rely on inline scripts, inline styles, analytics tags, embeds, or third-party widgets. Values such as unsafe-inline and unsafe-eval weaken the policy, so Website Certs flags them as warnings. A practical rollout starts with a report-only policy, removes unsafe patterns gradually, and tightens directives such as script-src, object-src, base-uri, and frame-ancestors.

X-Frame-Options

X-Frame-Options controls whether a page can be embedded in a frame. This helps defend against clickjacking, where an attacker hides a real page inside another interface and tricks a user into clicking something unintended. DENY blocks framing, and SAMEORIGIN allows framing only by pages from the same origin.

Modern CSP includes the frame-ancestors directive, which is more flexible, but X-Frame-Options remains a widely understood signal. For many sites, DENY or SAMEORIGIN is a simple and effective baseline.

X-Content-Type-Options

X-Content-Type-Options is usually set to nosniff. It tells browsers not to guess a file type when the Content-Type header says something else. That reduces the risk of a browser treating an uploaded or misconfigured file as executable script.

This header is short, but it is worth keeping. If a response says a file is text, image, CSS, JavaScript, or JSON, the browser should respect the declared type instead of trying to infer a different one.

Referrer-Policy

Referrer-Policy controls how much URL information is sent in the Referer header when a user follows a link or when the page loads cross-origin resources. Without a careful policy, paths and query strings can leak to other sites. That can expose campaign data, document names, internal paths, or sensitive values that should never have been put in URLs.

Common strong choices include no-referrer, same-origin, strict-origin, and strict-origin-when-cross-origin. Many modern sites use strict-origin-when-cross-origin because it preserves useful origin-level attribution while avoiding full URL leakage across origins.

Permissions-Policy

Permissions-Policy controls access to browser features such as camera, microphone, geolocation, fullscreen, payment, and other APIs. A policy can disable features entirely or allow them only for specific origins. It is useful because many sites do not need most powerful browser APIs on every page.

A good Permissions-Policy is application-specific. A documentation page may disable almost everything. A video app may need fullscreen. A checkout flow may need payment features. The goal is to allow what the product needs and block what it does not.

Common security header mistakes

The most common mistake is assuming headers are present because they were configured somewhere. The final response may be different after redirects, CDN rules, framework routes, or edge middleware. Another common mistake is copying a strict CSP from a template without testing the resources the site actually uses.

Teams also forget to check multiple hostnames. The apex domain, www domain, app subdomain, and documentation subdomain can have different headers. HSTS is another place to be careful: includeSubDomains can affect old systems that were not part of the original rollout.

• Check the final URL after redirects.
• Test strict CSP changes before enforcing them.
• Avoid unsafe-inline and unsafe-eval where possible.
• Use HSTS only after HTTPS is reliable.
• Review headers on every important public hostname.

How to check security headers

The simplest way to check security headers is to request the public HTTPS URL and inspect the final response headers. Look for Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, and Cross-Origin-Embedder-Policy.

The Website Certs Security Headers Checker does this for a public domain or URL. It follows redirects, records the final URL, shows the HTTP status code and response time, grades the result, and gives a clear recommendation for every checked header.

• Enter the exact domain or URL users visit.
• Review the overall grade and score.
• Fix missing critical headers first.
• Copy recommendations into your infrastructure or application task list.
• Recheck after deploying header changes.

How Website Certs can help

Website Certs provides a free Security Headers Checker for one-time public checks. It explains whether each important header is present, weak, or missing, then gives recommendations that are easier to act on than raw response headers alone.

For production domains, Website Certs can monitor security headers alongside SSL, HTTPS, DNS, and domain expiry signals. That helps catch regressions after deployments, CDN edits, framework upgrades, or infrastructure migrations.