SecPoint Logo
line background

Website security guide

What Are HTTP Security Headers?

HTTP security headers tell browsers how to handle your website more safely. They help reduce common risks such as clickjacking, content injection, MIME sniffing, unsafe referrers and weak transport protection.

Can content be injected?

Content Security Policy helps restrict where scripts, images, frames and other resources may load from.

Can pages be framed?

Frame controls help reduce clickjacking by limiting which sites may embed your pages.

Is transport enforced?

HSTS helps browsers use HTTPS and avoid accidental downgrade to plain HTTP.

Scan Website Headers Ask SecPoint

Header Outcome

Small Server Settings, Real Browser Protection

Security headers are sent by the web server and enforced by the browser before or while a page is rendered.

Restrict

Limit trusted resource sources.

Enforce

Require HTTPS connections.

Isolate

Reduce cross-origin risk.

Document

Show technical security checks.

effect

What Is an HTTP Security Header?

HTTP headers are metadata sent with web requests and responses. Security headers are response headers that tell the browser which behavior is allowed, which behavior should be blocked and how the site expects content to be handled.

They are not a replacement for secure coding, patching, access control or vulnerability scanning. They are a defensive layer that can reduce the impact of common web security mistakes and make exploitation harder.

Browser Rules

Tell browsers how to handle content, frames, referrers, features and transport security.

Server Controlled

Headers are normally configured in the web server, reverse proxy, CDN or application framework.

Defense in Depth

Headers help reduce risk even when application code or third-party content has weaknesses.

Auditable

Header checks are easy to test and document during web security reviews.

effect

Important HTTP Security Headers Today

These are the main security headers organizations should understand when hardening modern websites and web applications.

Content-Security-Policy

CSP helps restrict which sources can load scripts, styles, images, fonts, frames and other resources. It is one of the strongest browser-side defenses against content injection and XSS impact.

Strict-Transport-Security

HSTS tells browsers to use HTTPS for future requests to the site. It helps reduce downgrade and accidental plain-HTTP access after the browser has seen the policy.

X-Content-Type-Options

Using nosniff helps prevent browsers from guessing a different MIME type than the one declared by the server.

X-Frame-Options and frame-ancestors

These controls help reduce clickjacking. Modern sites often use the CSP frame-ancestors directive; X-Frame-Options is still commonly used for compatibility.

Referrer-Policy

Referrer-Policy controls how much URL information is shared when users navigate away from the site or load third-party resources.

Permissions-Policy

Permissions-Policy controls access to browser features such as camera, microphone, geolocation, payment, fullscreen and other powerful capabilities.

Recommended Starting Values for Security Headers

These examples are practical starting points. Test them before production use, because some websites need additional trusted domains for scripts, fonts, analytics, payments, videos, chat widgets or APIs.

Content-Security-Policy

Start restrictive, then add only the sources your website really needs.

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

Strict-Transport-Security

Use after confirming HTTPS works correctly for the site and subdomains.

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

X-Content-Type-Options

Prevent MIME type sniffing where browsers try to guess file types.

X-Content-Type-Options: nosniff

Frame Protection

Use CSP frame-ancestors, and optionally X-Frame-Options for compatibility.

Content-Security-Policy: frame-ancestors 'self'
X-Frame-Options: SAMEORIGIN

Referrer-Policy

Reduce unnecessary URL leakage while keeping useful referrer behavior.

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

Permissions-Policy

Disable powerful browser features unless the website explicitly needs them.

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

Cross-Origin-Opener-Policy

Helps isolate browsing contexts from cross-origin windows.

Cross-Origin-Opener-Policy: same-origin

Cross-Origin-Resource-Policy

Restrict who can load your resources from other origins.

Cross-Origin-Resource-Policy: same-origin

Cache-Control for Sensitive Pages

Use stricter cache controls for logged-in pages, account pages and sensitive data.

Cache-Control: no-store

Reporting-Endpoints

Optional. Use with CSP reporting if you have a reporting endpoint to collect violations.

Reporting-Endpoints: csp-endpoint="https://example.com/csp-report"

Cross-Origin and Isolation Headers

Modern web applications often load content from many origins. These headers help control how documents, resources and windows interact across origins.

Cross-Origin-Opener-Policy

COOP can isolate a browsing context from other origins and reduce risks from cross-origin window interactions.

Cross-Origin-Embedder-Policy

COEP controls whether a document can load cross-origin resources unless those resources explicitly allow it.

Cross-Origin-Resource-Policy

CORP lets a resource declare which origins are allowed to include it, helping protect resources from unwanted cross-origin use.

CORS Is Different

Cross-Origin Resource Sharing uses headers such as Access-Control-Allow-Origin. It is not called XCTO and should not be confused with X-Content-Type-Options.

Outdated or Deprecated Header Advice

Some older security headers still appear in legacy articles, scanners and server configurations. They should be understood carefully before being recommended.

Public-Key-Pins

HPKP is obsolete and should not be recommended for new deployments. Misconfiguration could lock users out of a site.

X-XSS-Protection

This legacy browser XSS filter header is deprecated. Modern sites should focus on CSP, output encoding and secure coding instead.

Feature-Policy

Feature-Policy was replaced by Permissions-Policy. Existing configurations should be reviewed and updated where appropriate.

Example Security Header Baseline

The right values depend on the application. Test carefully before enforcing strict policies, especially CSP and cross-origin isolation headers.

Copy-Paste Header Starting Point

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=(), payment=()
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin

Nginx Note

In Nginx, headers are commonly added with add_header. Use always where appropriate so headers are also sent on error responses.

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Apache Note

In Apache, headers are commonly added with Header always set. The headers module must be enabled.

Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

Do Not Copy Blindly

A CSP that is too strict can break a site. A policy that is too loose may add little value. Build, test, monitor and refine.

Cache-Control Depends on Content

Use strict cache controls for sensitive pages. Public static assets may need different caching for performance.

effect

Common Security Header Mistakes

Headers can improve security, but incorrect configuration can create false confidence or break important functionality.

Missing CSP

Without CSP, the browser has fewer restrictions if content injection becomes possible.

Overly Broad Sources

A policy allowing too many third-party sources may not meaningfully reduce risk.

Broken Third-Party Content

Strict policies can block analytics, payment scripts, fonts, videos or chat widgets if they are not planned correctly.

No HTTPS Enforcement

Sites that support HTTPS should consider HSTS after confirming HTTPS is correctly configured.

Legacy Header Dependence

Depending on obsolete headers instead of modern controls can leave a site weaker than expected.

No Retesting

Headers should be retested after CMS changes, CDN updates, framework changes and new third-party integrations.

How SecPoint® Helps Check Security Headers

SecPoint® Penetrator™ and Cloud Penetrator™ can help identify missing or weak security headers as part of vulnerability scanning and web exposure review.

Website Checks

Review public websites and web applications for missing security header controls.

TLS Review

Combine header checks with SSL/TLS configuration review for public web targets.

Clear Reports

Use findings to support remediation, customer communication and security project documentation.

Recurring Scans

Retest after changes and track whether web security hardening improves over time.

HTTP Security Header Questions

These questions help teams review security headers without relying on outdated checklists.

Do Security Headers Stop All Web Attacks?

No. Headers reduce specific browser-side risks, but they do not replace secure coding, patching, access control, input validation, authentication review or vulnerability scanning.

Which Header Should Be Implemented First?

Most sites should review HTTPS, HSTS, X-Content-Type-Options, Referrer-Policy, frame protections and CSP. CSP usually needs the most testing because it can block legitimate scripts and resources.

Should Every Website Use the Same Policy?

No. A static website, SaaS platform, e-commerce shop, customer portal and API documentation site may need different policies based on content, scripts, integrations and user data.

Why Do Header Scanners Give Different Results?

Tools may score headers differently. Some check for presence only, while better reviews consider whether the policy is strict, relevant and compatible with the application.

Can a CDN Add Security Headers?

Yes, many CDNs and reverse proxies can add or rewrite headers. Teams should verify that final browser responses contain the expected headers after CDN, proxy and application processing.

How Often Should Headers Be Retested?

Retest after application releases, CMS changes, CDN changes, new third-party scripts, payment integrations, authentication changes and server migrations.

Check Your Website Security Headers

Talk to SecPoint® about web vulnerability scanning, missing security headers, TLS review, public exposure checks and practical remediation reporting.

View Cloud Penetrator Contact SecPoint

Suggested Content

Cloud Penetrator SecPoint Penetrator Reflected XSS
Complete Guide to Vulnerability Scanning Free Vulnerability Scan Contact SecPoint