Learn what HTTP security headers do, including CSP, HSTS, X-Content-Type-Options, Referrer-Policy and clickjacking protection, plus how to audit them safely.

Website security is often associated with dramatic things: firewalls, malware scanners, penetration testing and emergency incident response.

But some valuable protections are much quieter.

They arrive as a handful of text lines sent by your web server with each response.

These are HTTP security headers.

A visitor normally never sees them. There is no security popup and no new button. Instead, the headers tell the browser how it should behave: what content it may execute, whether the website should always use HTTPS, whether the page can be embedded elsewhere, how much referral information should be shared, and more.

OWASP describes properly configured HTTP response headers as an effective additional layer against problems including cross-site scripting, clickjacking and information disclosure. 

They are not a replacement for secure PHP code, authentication, input validation or software updates.

Think of them as browser-enforced guardrails.

Content Security Policy: Control What the Browser Is Allowed to Load

Content Security Policy, commonly called CSP, is one of the most powerful browser-side defenses available to website owners.

A CSP can specify which origins are allowed to provide scripts, images, fonts, frames and other resources.

Why does that matter?

Imagine an attacker manages to inject a piece of unwanted JavaScript into an otherwise legitimate page. Without additional restrictions, the browser may simply execute it.

A carefully designed CSP can make many such injections considerably harder to exploit because the browser has an independent rule describing which scripts are acceptable.

MDN describes CSP as a mechanism for controlling which resources a page may load, while OWASP recommends CSP as an important defense against classes of attacks such as cross-site scripting and data injection. 

However, CSP is also the header most likely to break a complex website if copied blindly.

A site might legitimately use analytics, payment providers, Turnstile, externally hosted fonts, Livewire behavior, embedded media or other third-party resources.

A policy that simply says “allow nothing except my own domain” could block necessary functionality.

The professional approach is to inventory required resources, build the policy deliberately, test thoroughly, and consider using report-only deployment while refining a restrictive policy.

Security configuration should fit the application—not the other way around.

HSTS: Tell Browsers to Stay on HTTPS

HTTPS encrypts the connection between the visitor and your website.

But what happens if someone manually enters an http:// URL?

Normally the server may receive an HTTP request and redirect the visitor to HTTPS.

HTTP Strict Transport Security, or HSTS, allows a site to tell browsers that future connections to the domain should use HTTPS directly.

The Strict-Transport-Security header contains a duration called max-age. Once a browser accepts the policy over HTTPS, it remembers that requirement for the specified period. 

That can strengthen HTTPS enforcement.

But there is an operational warning.

If you enable a very long HSTS duration—and particularly includeSubDomains—you are promising that the covered hosts will remain available through valid HTTPS.

OWASP explicitly recommends understanding the consequences before using aggressive HSTS settings because certificate or HTTPS problems can make a protected host inaccessible to users until the policy expires. 

Start deliberately rather than pasting the strongest configuration you find in a random “security score” tutorial.

X-Content-Type-Options: Don't Guess What This File Is

Web servers send a Content-Type describing the type of a response.

For example, CSS should be served as CSS and JavaScript should be served using an appropriate JavaScript media type.

Historically, browsers sometimes attempted to infer—or “sniff”—a resource's type instead of strictly trusting the declared value.

That flexibility can create security problems when untrusted content is served with an incorrect type.

The widely used protection is:

X-Content-Type-Options: nosniff

MDN explains that nosniff tells browsers to respect the advertised MIME type instead of trying to infer a different one. 

This is particularly relevant on websites that work with user-provided files.

It does not make a malicious upload safe by itself. File uploads still need type validation, safe storage, controlled filenames and other defenses. OWASP specifically recommends multiple layers rather than trusting an extension or client-supplied Content-Type. 

Clickjacking Protection: Who Is Allowed to Frame Your Page?

Imagine your login page is secretly loaded inside an invisible frame on another website.

The attacker places deceptive interface elements over it and persuades a visitor to click somewhere they did not intend.

That general technique is known as clickjacking.

Historically, X-Frame-Options was commonly used to control framing.

Modern CSP provides the frame-ancestors directive, which OWASP recommends as the preferred mechanism for browsers that support it. 

The appropriate rule depends on your application.

Some websites should never be framed by anybody.

Others intentionally provide widgets designed for embedding.

Once again, blindly maximizing a security score can be harmful if it disables a legitimate feature.

Understand the behavior first.

Referrer-Policy: Decide How Much Navigation Information Leaves the Site

When a browser requests another page or external resource, it may include information indicating where the request came from.

That information can be useful for analytics, but exposing unnecessarily detailed URLs can also create privacy concerns.

Referrer-Policy lets you control how much referrer information is sent.

For many ordinary sites, strict-origin-when-cross-origin provides a useful balance: same-origin navigation can retain detailed referrer information, while cross-origin requests receive the origin rather than the complete path. OWASP recommends this policy as a sensible explicit baseline, and MDN documents its behavior. 

The correct setting still depends on the website's needs.

If URLs may contain sensitive information, consider the privacy implications particularly carefully.

And ideally, sensitive data should not be placed in URLs in the first place.

Permissions Policy: Disable Browser Capabilities You Don't Need

Modern browsers expose powerful capabilities, including access to cameras, microphones, geolocation and other features.

Permissions Policy provides a mechanism for controlling which origins are allowed to use supported browser features. 

For example, a website that never uses geolocation can explicitly restrict it.

That follows a useful security principle: if the application does not need a capability, there is little reason to expose it unnecessarily.

Permissions Policy requires more care than older headers because individual directives and browser support evolve. MDN currently marks the broader header technology as having areas of limited availability, so production configurations should be based on the features you actually use and tested in the browsers important to your audience. 

Cache-Control Can Also Be a Security Decision

Caching is usually discussed as a performance feature.

For sensitive pages, it can also become a security consideration.

A public product page may benefit from aggressive caching.

A response containing personal or confidential information may require different treatment.

OWASP recommends no-store when sensitive responses should not be stored and explains that private prevents shared caches from storing a response while still permitting private caches. 

The mistake is applying one cache rule everywhere.

Security headers work best when they reflect the content being served.

Why “A+ Security Headers” Does Not Mean “A Secure Website”

Header-checking tools are useful.

They can quickly reveal obvious omissions and misconfigurations.

But a perfect scanner result does not mean the application itself is secure.

A website can have excellent CSP and HSTS configuration while still containing:

SQL injection,

broken authorization,

unsafe file uploads,

exposed secrets,

weak authentication,

vulnerable dependencies,

or business-logic flaws.

Likewise, a scanner may criticize a missing header that provides little value for a particular endpoint.

Treat the score as diagnostic information, not a security certificate.

OWASP's guidance is valuable precisely because it explains what each header protects against rather than reducing security to a number. 

Audit First, Change Second

The safest process for a production site is simple.

Inspect the headers currently returned.

Understand why each one is present or absent.

Identify third-party scripts, frames and APIs the website genuinely requires.

Introduce restrictive policies carefully.

Test authentication, forms, payments, analytics, CAPTCHA, media processing and embedded resources afterward.

Monitor errors.

Then tighten policies gradually where appropriate.

That approach is slower than copying a block from a blog post, but it is much less likely to break a live application.

Security is not about maximizing the number of headers.

It is about reducing meaningful risk while preserving legitimate functionality.

The Small Details Matter

HTTP headers are appealing because many of them require only a small configuration change.

Their effect can be significant because browsers enforce the resulting policy for every visitor.

CSP can restrict resource execution.

HSTS strengthens HTTPS usage.

nosniff reduces MIME confusion.

Framing controls reduce clickjacking exposure.

Referrer Policy limits unnecessary navigation information.

Permissions Policy can restrict access to browser capabilities.

Cache rules can help keep sensitive responses out of inappropriate storage.

None of them replaces secure application code.

Together, however, they form an inexpensive additional layer of defense—and one that every serious website owner should understand.