Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.
In this guide
- Key takeaways
- Which HTTP security header forces browsers to use HTTPS only?
- How does Content - Security - Policy protect against XSS and data injection?
- Why should I send X - Content - Type - Options: nosniff?
- What header prevents click - jacking attacks?
- How can I limit referrer information sent to other sites?
- Which header restricts use of risky browser features?
- How does Cross - Origin - Opener - Policy improve isolation?
- What does Cross - Origin - Embedder - Policy enforce?
- How can I restrict which origins may load my resources?
- Why should I disable DNS prefetching?
- Should I keep server version headers like Server or X-Powered-By?
- How can I verify that all required headers are present?
- What are the next steps after adding the headers?
Key takeaways
- Add HSTS, CSP, X - Content - Type - Options, X - Frame - Options, Referrer - Policy, Permissions - Policy, COOP, COEP, CORP, X - DNS - Prefetch - Control, and remove information - leakage headers.
- Use the recommended values below as a baseline; adjust CSP and Permissions - Policy to your app’s needs.
- Verify the headers with a free Decloak scan; the core Layer 1 check will flag any missing header and show the exact response.
Which HTTP security header forces browsers to use HTTPS only?
The Strict - Transport - Security (HSTS) header tells browsers to always connect via HTTPS, eliminating protocol - downgrade attacks. Add it as:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Set max-age to at least two years (63072000 seconds) and include preload if you submit to the Chrome preload list.
How does Content - Security - Policy protect against XSS and data injection?
CSP restricts where scripts, styles, images and other resources can be loaded from, dramatically reducing the impact of XSS. A solid baseline is:
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; object-src 'none'; base-uri 'self';
Customize the directives to match the external services your site uses.
Why should I send X - Content - Type - Options: nosniff?
Browsers try to guess a file’s MIME type, which can cause a script to execute even when served as text/plain. The nosniff directive disables this behavior:
X-Content-Type-Options: nosniff
Apply it to every response that serves HTML, JavaScript, CSS, or JSON.
What header prevents click - jacking attacks?
X-Frame-Options (or the CSP frame-ancestors directive) blocks other sites from embedding your page in a frame. The simplest setting is:
X-Frame-Options: DENY
If you need to allow framing from the same origin, use SAMEORIGIN instead.
How can I limit referrer information sent to other sites?
Referrer-Policy controls how much URL data browsers include in the Referer header. A privacy - preserving default is:
Referrer-Policy: strict-origin-when-cross-origin
This sends the full URL only for same - origin requests and only the origin for cross - origin navigations.
Which header restricts use of risky browser features?
Permissions-Policy (formerly Feature-Policy) disables features like camera, microphone, and geolocation unless explicitly allowed. Example:
Permissions-Policy: geolocation=(), camera=(), microphone=(), fullscreen=()
List the features your app actually needs; set the rest to empty parentheses.
How does Cross - Origin - Opener - Policy improve isolation?
Cross-Origin-Opener-Policy (COOP) separates your top - level page from cross - origin documents, mitigating side - channel attacks such as Spectre. Use:
Cross-Origin-Opener-Policy: same-origin
Pair it with COEP for full site isolation.
What does Cross - Origin - Embedder - Policy enforce?
Cross-Origin-Embedder-Policy (COEP) requires cross - origin resources to grant permission via CORP or CORS, preventing malicious inclusion. Add:
Cross-Origin-Embedder-Policy: require-corp
This works best when you also serve resources with the appropriate Cross-Origin-Resource-Policy header.
How can I restrict which origins may load my resources?
Cross-Origin-Resource-Policy (CORP) tells browsers which origins are allowed to request the resource. A safe default is:
Cross-Origin-Resource-Policy: same-site
Use same-origin if you want stricter isolation.
Why should I disable DNS prefetching?
X-DNS-Prefetch-Control prevents browsers from resolving domain names before a user clicks a link, reducing unnecessary traffic and information leakage. Set it to:
X-DNS-Prefetch-Control: off
Apply it to all HTML responses.
Should I keep server version headers like Server or X-Powered-By?
Headers that reveal server software or framework versions help attackers craft targeted exploits. Remove or mask them, for example:
Server: webserver
X-Powered-By: hidden
Or simply omit the headers entirely.
How can I verify that all required headers are present?
Run a free Decloak scan on your URL. The core Layer 1 (HTTP/TLS security posture) check lists any missing security headers and shows the exact response values, letting you confirm that each header is correctly applied.
What are the next steps after adding the headers?
- Deploy the header changes in a staging environment.
- Run the Decloak free scan again to ensure no header is still missing.
- Monitor the scan’s executive summary for any new findings.
- Document the header configuration in your deployment scripts to keep it version - controlled.
This article follows the eight core layers of Decloak’s free scan. Layer 1 flags missing HTTP/TLS headers, while the other layers cover HTML, network behavior, JavaScript libraries, tag managers, third - party domains, platform security, and an AI - written summary.
Related guides
How to Fix a Missing Content - Security - Policy Header
Learn concrete steps to add, test, and harden a Content - Security - Policy header, from server configuration to iterative reporting and verification.
Is HTTP 1.1 a security risk?
HTTP 1.1 is not a direct vulnerability, but its plain - text design and parsing ambiguities can create attack surfaces that need mitigation, especially when not used over TLS.
Is JavaScript a security risk?
JavaScript can be a major attack surface because injected scripts run with the same privileges as the page, but proper sanitization, CSP, and safe frameworks eliminate most risks.