Security Headers You Should Know

Introduction

Security headers are HTTP response headers that tell browsers how to handle your website more safely. They can help reduce risks such as clickjacking, MIME sniffing, insecure referrer leakage, mixed content, weak HTTPS behavior and unnecessary browser permissions.

Security headers do not replace secure code, updates or server hardening, but they add an important browser-side protection layer. Some headers are simple to enable, while others, especially Content-Security-Policy and HSTS, should be tested carefully before strict enforcement.

Quick answer

Security headers

Security headers are instructions sent by a website server in the HTTP response. Browsers read these headers and apply extra security rules when loading the page.

They can help control:

• whether the site can be embedded in frames
• whether browsers can guess file types
• how much referrer information is shared
• whether HTTPS should always be used
• which scripts, styles and images can load
• which browser features are allowed
• how cross-origin resources behave

Security headers are most useful when combined with HTTPS, secure application code, updated software and proper server configuration.

Important headers

Low-risk headers

Some headers are usually safer to enable first because they are less likely to break normal websites.

Good starting headers:

• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• X-Frame-Options: SAMEORIGIN
• Permissions-Policy with only needed features allowed

Headers to test carefully

Some headers can break website features if configured too strictly.

Content-Security-Policy

Content-Security-Policy, or CSP, is one of the most powerful security headers. It tells browsers which sources are allowed to load scripts, styles, images, fonts, frames and other resources.

CSP can help reduce:

• cross-site scripting impact
• malicious script injection
• unauthorized third-party resources
• mixed content
• unsafe inline scripts when configured strictly

Content-Security-Policy: default-src 'self'; img-src 'self' https:; object-src 'none'; frame-ancestors 'self';

HSTS

Strict-Transport-Security, or HSTS, tells browsers to use HTTPS automatically for future visits.

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

Benefits:

• reduces accidental HTTP usage
• helps prevent protocol downgrade attacks
• improves HTTPS consistency

Why this matters

Missing headers do not always mean a website is hacked or unsafe, but they usually indicate room for better hardening.

How to check headers

Use HTTP Header Checker to see which headers your website returns.

Check:

1. Homepage — Review headers on the main URL.
2. HTTPS version — Confirm headers are present on the final HTTPS response.
3. Important pages — Check login, checkout, admin, contact and application pages.
4. Redirects — Confirm headers appear on final pages, not only redirects.
5. CSP behavior — Check whether CSP blocks required resources.
6. HSTS readiness — Confirm SSL works across required subdomains before strict HSTS.
7. CDN/proxy layer — Check whether headers are added by origin, CDN or both.

Common problems

How to improve headers

1. Step 1: Audit current headers

   Run HTTP Header Checker on the homepage and important pages.

2. Step 2: Add low-risk headers first

   Start with nosniff, referrer policy, frame protection and permissions policy.

3. Step 3: Test important flows

   Check login, checkout, contact forms, embeds, analytics and dashboards.

4. Step 4: Plan CSP carefully

   Use report-only mode first and review violations.

5. Step 5: Enable CSP enforcement gradually

   Allow only trusted resources and avoid broad wildcards where possible.

6. Step 6: Prepare HSTS

   Confirm HTTPS works on the main domain and required subdomains.

7. Step 7: Check CDN/origin consistency

   Make sure headers are not duplicated, missing or overwritten.

8. Step 8: Monitor after deployment

   Watch browser console errors, user reports and analytics changes.

Security headers can be added in different places:

• Nginx configuration
• Apache .htaccess or vhost
• CDN response header rules
• hosting control panel
• WordPress plugin
• application framework
• edge worker/function

Check headers:
curl -I https://example.com

Check final response after redirects:
curl -IL https://example.com

Look for:
content-security-policy
strict-transport-security
x-frame-options
x-content-type-options
referrer-policy
permissions-policy

Example Nginx header:
add_header X-Content-Type-Options "nosniff" always;

Example Apache header:
Header always set X-Content-Type-Options "nosniff"

Example header set

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: SAMEORIGIN
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content-Security-Policy: default-src 'self'; img-src 'self' https:; object-src 'none'; frame-ancestors 'self';
Strict-Transport-Security: max-age=31536000; includeSubDomains

WordPress headers

WordPress security headers can be added through the server, CDN, security plugin or application code.

Check carefully when using:

• caching plugins
• security plugins
• page builders
• analytics scripts
• embedded forms
• payment widgets
• Google Maps
• YouTube embeds
• external fonts
• CDN-hosted assets

Frequently asked questions