HTTP Headers
Inspect HTTP request and response headers, including redirects.
Initial Request
HTTP Headers
HTTP headers are metadata sent between browsers and servers during web requests. They control caching, security, authentication, and content negotiation. Response headers reveal server configuration and security posture.
HTTP Headers
HTTP headers are metadata sent between browsers and servers during web requests. They control caching, security, authentication, and content negotiation. Response headers reveal server configuration and security posture.
t.co
Request Headers
| Host: | t.coCopied |
| user-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:64.0) Gecko/20100101 Firefox/64.0Copied |
| accept: | */*Copied |
| accept-language: | en-usCopied |
| connection: | closeCopied |
Response Headers
| date: | Tue, 14 Jul 2026 19:34:45 GMTCopied |
| content-type: | text/html;charset=utf-8Copied |
| server: | cloudflare envoyCopied |
| cache-control: | no-cache, no-store, max-age=0Copied |
| x-xss-protection: | 0Copied |
| content-security-policy: | default-src 'none'; img-src https://abs.twimg.com; script-src https://abs.twimg.com about:; style-src https://abs.twimg.com 'unsafe-inline'; font-src https://abs.twimg.com https://twitter.com; connect-src 'none'; object-src 'none'; media-src 'none'; frame-src 'none'; report-uri https://twitter.com/i/csp_report?a=ORTGK%3D%3D%3D&ro=falseCopied |
| set-cookie: | __cf_bm=4_DuNKib948dtSjBVMBEYQgP8CwAiQdAHF9VRaRiQK0-1784057685.0143237-1.0.1.1-UGqHxu9iKcaYqLl0P4ONQbqc0tXlcVkvCqpjpRdEakrvVu__7O7jYUvvo7c1UVpD61mqDEWKRGmj10Ue8ZvVgW0TERVxvDzLY1.0s8CtzKt_pOeEdbIrdeIp0KVLuNvd; HttpOnly; SameSite=None; Secure; Path=/; Domain=t.co; Expires=Tue, 14 Jul 2026 20:04:45 GMTCopied |
| x-response-time: | 11Copied |
| origin-cf-ray: | a1b2f77358fa9c18-IADCopied |
| strict-transport-security: | max-age=631138519; includeSubdomainsCopied |
| x-served-by: | t4_aCopied |
| cf-cache-status: | DYNAMICCopied |
| vary: | accept-encodingCopied |
| cf-ray: | a1b2f77358fa9c18-IADCopied |
Core Security Headers
Core Security Headers
These 6 HTTP response headers form the foundation of browser-side security. Each addresses a specific attack vector — from man-in-the-middle attacks to clickjacking to cross-site scripting. Sites are graded A+ through F based on how many of these headers are present.
What You'll See
- ✅ Header is present in the response
- ❌ Header is missing — a potential security gap
- ⚠️ Header is present but has a weak configuration
Diagnostic Value
- A+ means all 6 core headers are present with no warnings (server version leaks, exposed cookies, etc)
- Most sites score D or F — even major companies often miss Permissions-Policy and Referrer-Policy
- Adding all 6 headers is straightforward in most web servers and frameworks
Why It Matters
Security headers are your first line of defense at the browser level. They cost nothing to implement, require no code changes, and protect against entire categories of attacks. A missing Content-Security-Policy alone can make your site vulnerable to XSS attacks.
History
Security headers evolved over 15+ years: X-Frame-Options (2009), X-Content-Type-Options (2008), HSTS (RFC 6797, 2012), CSP (2012), Referrer-Policy (2017), Permissions-Policy (2020). Each was created in response to real-world attacks.
Core Security Headers
These 6 HTTP response headers form the foundation of browser-side security. Each addresses a specific attack vector — from man-in-the-middle attacks to clickjacking to cross-site scripting. Sites are graded A+ through F based on how many of these headers are present.
What You'll See
- ✅ Header is present in the response
- ❌ Header is missing — a potential security gap
- ⚠️ Header is present but has a weak configuration
Diagnostic Value
- A+ means all 6 core headers are present with no warnings (server version leaks, exposed cookies, etc)
- Most sites score D or F — even major companies often miss Permissions-Policy and Referrer-Policy
- Adding all 6 headers is straightforward in most web servers and frameworks
Why It Matters
Security headers are your first line of defense at the browser level. They cost nothing to implement, require no code changes, and protect against entire categories of attacks. A missing Content-Security-Policy alone can make your site vulnerable to XSS attacks.
History
Security headers evolved over 15+ years: X-Frame-Options (2009), X-Content-Type-Options (2008), HSTS (RFC 6797, 2012), CSP (2012), Referrer-Policy (2017), Permissions-Policy (2020). Each was created in response to real-world attacks.
Strict-Transport-Security (HSTS)
HSTS tells browsers to always use HTTPS when connecting to your site, even if the user types http:// or clicks an HTTP link. Once a browser sees this header, it will refuse to connect over plain HTTP for the duration specified by max-age.
What You'll See
- max-age — How long (in seconds) the browser should remember to force HTTPS. 31536000 = 1 year.
- includeSubDomains — Also enforce HTTPS on all subdomains
- preload — Opt into browser preload lists so HTTPS is enforced before the first visit
Diagnostic Value
- Without HSTS, the first request to your site may go over HTTP, allowing SSL stripping attacks
- A max-age under 31536000 (1 year) is considered weak — attackers can wait for it to expire
- The preload directive gets your domain hardcoded into Chrome, Firefox, Safari, and Edge
Why It Matters
HSTS closes the gap between 'having HTTPS' and 'always using HTTPS.' Without it, an attacker on the network can intercept the initial HTTP request and downgrade the connection. This is called an SSL stripping attack, and it's trivially easy on public WiFi.
Good Values
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
History
Defined in RFC 6797 (2012). Created after researcher Moxie Marlinspike demonstrated SSL stripping attacks at Black Hat DC 2009 with his tool 'sslstrip'. The HSTS preload list launched in Chrome 2012 and is now shared across all major browsers.
Content-Security-Policy (CSP)
CSP is the most powerful security header available. It tells the browser exactly which sources of content are allowed to load — scripts, styles, images, fonts, frames, and more. Any resource not matching the policy is blocked, making XSS attacks dramatically harder to execute.
What You'll See
- default-src — Fallback policy for all resource types not explicitly listed
- script-src — Which origins can serve JavaScript (the most critical directive)
- style-src — Where CSS can be loaded from
- img-src, font-src, connect-src, frame-src — Per-resource-type controls
Diagnostic Value
- A missing CSP is the single biggest security gap most sites have
- 'unsafe-inline' in script-src significantly weakens CSP — it allows inline scripts, which is how most XSS payloads execute
- 'unsafe-eval' allows eval(), Function(), and setTimeout with strings — another XSS vector
- report-uri or report-to directives let you monitor violations without blocking (great for rollout)
Why It Matters
Cross-site scripting (XSS) has been in the OWASP Top 10 for over 20 years. CSP is the browser-level defense that makes XSS exploitation vastly more difficult even when your application code has vulnerabilities. It's defense in depth — if a bug lets an attacker inject HTML, CSP prevents that HTML from loading malicious scripts.
Good Values
Start with: Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; Then tighten as needed.
History
CSP 1.0 was introduced by Mozilla in 2012 (W3C Candidate Recommendation). CSP 2.0 added nonce-based and hash-based script whitelisting (2015). CSP 3.0 (current) adds strict-dynamic and improved reporting. Google research shows that traditional CSP allowlists are bypassable in 94% of cases — nonce-based CSP is now recommended.
X-Frame-Options
Controls whether your page can be embedded in an iframe, frame, or object element on another site. This is the primary defense against clickjacking attacks, where an attacker overlays your site with transparent elements to trick users into clicking hidden buttons.
What You'll See
- DENY — Page cannot be framed by anyone, including your own site
- SAMEORIGIN — Page can only be framed by pages on the same origin
- ALLOW-FROM uri — (Deprecated) Only allow framing from a specific origin
Diagnostic Value
- DENY is the safest option if your site doesn't need to be embedded anywhere
- SAMEORIGIN is needed if you iframe your own pages (e.g., admin panels, previews)
- ALLOW-FROM is deprecated and not supported in modern browsers — use CSP frame-ancestors instead
- CSP's frame-ancestors directive is the modern replacement and is more flexible
Why It Matters
Clickjacking tricks users into performing actions they didn't intend — clicking 'Delete Account,' authorizing payments, or changing security settings. The attack is invisible because your real site is loaded in a transparent iframe positioned over the attacker's decoy page.
Good Values
X-Frame-Options: DENY (or SAMEORIGIN if you embed your own content)
History
Introduced by Microsoft in Internet Explorer 8 (2009) as a response to clickjacking attacks. Standardized in RFC 7034 (2013). Being gradually superseded by CSP frame-ancestors, but still widely used for backward compatibility.
X-Frame-Options: DENY
X-Content-Type-Options
Prevents browsers from 'MIME sniffing' — guessing the content type of a response instead of trusting the Content-Type header. Without this, a browser might execute a file as JavaScript even if the server says it's text/plain.
What You'll See
- nosniff — The only valid value. Tells the browser to strictly follow the declared Content-Type
Diagnostic Value
- This header has exactly one valid value: nosniff
- Without it, attackers can upload files that look like images but are executed as scripts
- Particularly important for sites that host user-uploaded content
- The simplest security header to implement — one line, one value, no configuration
Why It Matters
MIME sniffing is a legacy browser behavior where the browser ignores what the server says a file is and tries to detect it automatically. An attacker uploads a file with JavaScript inside but named .jpg — without nosniff, the browser might execute it. This header eliminates that entire attack class.
Good Values
X-Content-Type-Options: nosniff
History
Introduced by Microsoft in Internet Explorer 8 (2008). Now supported by all major browsers. One of the easiest security wins — a single header value that eliminates MIME-confusion attacks.
X-Content-Type-Options: nosniff
Referrer-Policy
Controls how much URL information is sent in the Referer header when a user navigates away from your site or loads external resources. Without this header, the full URL (including query parameters, paths, and potentially sensitive data) may be leaked to third parties.
What You'll See
- no-referrer — Never send the Referer header
- no-referrer-when-downgrade — Send full URL for HTTPS→HTTPS, nothing for HTTPS→HTTP (browser default)
- origin — Only send the origin (https://example.com), not the full path
- strict-origin-when-cross-origin — Full URL for same-origin, origin-only for cross-origin, nothing for downgrade (recommended)
Diagnostic Value
- Query parameters often contain tokens, session IDs, search terms, or user data
- Without this header, visiting https://example.com/account?token=abc123 leaks the full URL to any external resource loaded on that page
- Analytics services, ad networks, and embedded widgets all receive your Referer by default
- strict-origin-when-cross-origin is the best balance of privacy and functionality
Why It Matters
URLs often contain sensitive information — password reset tokens, search queries, internal paths, API keys in query strings. The Referer header sends this information to every external resource your page loads. Referrer-Policy prevents this silent data leak.
Good Values
Referrer-Policy: strict-origin-when-cross-origin (recommended) or no-referrer (strictest)
History
Introduced as a W3C specification in 2017. The misspelling 'Referer' (one 'r') dates back to the original HTTP/1.0 spec (RFC 1945, 1996) — a typo by Phillip Hallam-Baker that was standardized before anyone noticed. The Referrer-Policy header uses the correct spelling.
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy
Controls which browser features and APIs your site (and its embedded iframes) can access — camera, microphone, geolocation, payment, USB, and dozens more. Without this header, any iframe embedded on your page can request these permissions.
What You'll See
- camera=() — Disable camera access entirely
- microphone=() — Disable microphone access
- geolocation=(self) — Allow geolocation only for your own origin
- payment=(self "https://pay.example.com") — Allow Payment API from your origin and a specific payment provider
Diagnostic Value
- Empty parentheses () means the feature is disabled for everyone, including your own site
- (self) allows only your own origin
- Without this header, third-party iframes can request camera/mic/location access from your users
- This is the most commonly missing security header — even security-conscious sites often skip it
Why It Matters
Third-party scripts and iframes embedded on your site can request powerful permissions from your users. A malicious or compromised ad script could request camera access while the user thinks they're granting it to your site. Permissions-Policy puts you in control of what features any code on your page can use.
Good Values
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=()
History
Originally called Feature-Policy (2018), renamed to Permissions-Policy in 2020. The rename reflected a broader scope — from controlling 'features' to controlling 'permissions' that affect user privacy and security. Still relatively new, with adoption growing steadily.
Permissions-Policy: camera=(), microphone=(), geolocation=()
Bonus Headers
Bonus Security Headers
Cross-Origin headers provide additional isolation between origins. They're newer and not yet widely adopted, but they enable powerful security features like Cross-Origin Isolation which is required for SharedArrayBuffer and high-resolution timers.
What You'll See
- ✅ Header is present — site has adopted this newer standard
- ➖ Header is absent — not penalized in grading, but worth considering
Diagnostic Value
- COEP, COOP, and CORP work together to enable Cross-Origin Isolation
- Required for APIs like SharedArrayBuffer (used in WebAssembly, video processing)
- Adoption is still low — these headers are most relevant for sites using advanced browser APIs
Why It Matters
These headers defend against speculative execution attacks (like Spectre) by controlling how resources are shared across origins. While not critical for every site, they represent the future direction of web security.
History
All three headers emerged around 2020 in response to Spectre-class CPU vulnerabilities. Browsers needed a way for sites to opt into stricter isolation to safely expose powerful but dangerous APIs.
Bonus Security Headers
Cross-Origin headers provide additional isolation between origins. They're newer and not yet widely adopted, but they enable powerful security features like Cross-Origin Isolation which is required for SharedArrayBuffer and high-resolution timers.
What You'll See
- ✅ Header is present — site has adopted this newer standard
- ➖ Header is absent — not penalized in grading, but worth considering
Diagnostic Value
- COEP, COOP, and CORP work together to enable Cross-Origin Isolation
- Required for APIs like SharedArrayBuffer (used in WebAssembly, video processing)
- Adoption is still low — these headers are most relevant for sites using advanced browser APIs
Why It Matters
These headers defend against speculative execution attacks (like Spectre) by controlling how resources are shared across origins. While not critical for every site, they represent the future direction of web security.
History
All three headers emerged around 2020 in response to Spectre-class CPU vulnerabilities. Browsers needed a way for sites to opt into stricter isolation to safely expose powerful but dangerous APIs.
Cross-Origin-Embedder-Policy (COEP)
Requires all cross-origin resources loaded by your page to explicitly opt in via CORS headers or CORP. This prevents your page from loading resources that haven't granted permission, enabling Cross-Origin Isolation.
What You'll See
- require-corp — All cross-origin resources must have a CORP header or CORS headers
- credentialless — Cross-origin requests are sent without credentials (cookies, client certs)
- unsafe-none — No restrictions (default)
Diagnostic Value
- Required (along with COOP) to enable Cross-Origin Isolation
- Cross-Origin Isolation is needed for SharedArrayBuffer and high-resolution timers
- Can break third-party resources that don't set CORS/CORP headers
- credentialless is a less restrictive alternative to require-corp
Why It Matters
COEP is part of the response to Spectre-class CPU vulnerabilities. Without Cross-Origin Isolation, browsers restrict access to APIs like SharedArrayBuffer that could be used to exploit timing-based side-channel attacks. COEP ensures your page only loads resources that have explicitly opted in.
History
Introduced in 2020 as part of the post-Spectre security model. Spectre (2018) showed that any data in a process's memory could potentially be read via CPU speculation. COEP helps browsers safely re-enable powerful APIs by ensuring resource isolation.
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy (COOP)
Controls whether your page shares a browsing context group with cross-origin windows that open it (or that it opens). When set to same-origin, your page is isolated in its own process, preventing cross-origin windows from accessing it via window.opener.
What You'll See
- same-origin — Only same-origin windows can share a browsing context with this page
- same-origin-allow-popups — Same as same-origin, but allows popups opened by your page to maintain a reference
- unsafe-none — No restrictions (default)
Diagnostic Value
- Required (along with COEP) for Cross-Origin Isolation
- Prevents cross-origin pages from getting a reference to your window object
- May break OAuth/SSO popup flows that rely on window.opener communication
- same-origin-allow-popups is a safer middle ground for sites using popup-based auth
Why It Matters
When a cross-origin page opens your site (or vice versa), they can share a browsing context, potentially allowing Spectre-class attacks to read memory across origins. COOP isolates your page into its own process, closing this attack vector.
History
Introduced alongside COEP in 2020 as part of the post-Spectre browser security model. Together with COEP, it enables the crossOriginIsolated property in JavaScript, which gates access to powerful but potentially dangerous APIs.
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy (CORP)
Tells the browser which origins are allowed to load this resource. Unlike CORS (which is for APIs), CORP protects static resources like images, scripts, and stylesheets from being loaded by unauthorized origins.
What You'll See
- same-origin — Only pages from the same origin can load this resource
- same-site — Pages from the same site (e.g., sub.example.com can load resources from example.com)
- cross-origin — Any origin can load this resource
Diagnostic Value
- CORP is set on individual resources, not on HTML pages
- Prevents your resources from being embedded on malicious sites
- Required by COEP: if your page uses require-corp, all cross-origin resources must have CORP set
- Most CDN-hosted resources should use cross-origin; private resources should use same-origin
Why It Matters
Without CORP, any website can embed your images, scripts, and other resources. While hotlinking is annoying, the security concern is deeper — Spectre attacks can potentially read the contents of any resource loaded into a page's process. CORP ensures your resources are only loaded where you intend.
History
Introduced in 2020 as the resource-level complement to COEP and COOP. While CORS has existed since 2006 for API access control, CORP fills the gap for non-API resources like images and scripts that don't go through fetch/XHR.
Cross-Origin-Resource-Policy: same-origin
⚠️ Warnings
X-XSS-Protection header is deprecated and can introduce vulnerabilities in older browsers. Use Content-Security-Policy instead.--- REQUEST --- GET / HTTP/2 Host: t.co user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:64.0) Gecko/20100101 Firefox/64.0 accept: */* accept-language: en-us connection: close --- RESPONSE --- HTTP/2 404 date: Tue, 14 Jul 2026 19:34:45 GMT content-type: text/html;charset=utf-8 server: cloudflare envoy cache-control: no-cache, no-store, max-age=0 x-xss-protection: 0 content-security-policy: default-src 'none'; img-src https://abs.twimg.com; script -src https://abs.twimg.com about:; style-src https://abs.twimg.com 'unsafe-inline' ; font-src https://abs.twimg.com https://twitter.com; connect-src 'none'; object-s rc 'none'; media-src 'none'; frame-src 'none'; report-uri https://twitter.com/i/cs p_report?a=ORTGK%3D%3D%3D&ro=false set-cookie: __cf_bm=4_DuNKib948dtSjBVMBEYQgP8CwAiQdAHF9VRaRiQK0-1784057685.0143237 -1.0.1.1-UGqHxu9iKcaYqLl0P4ONQbqc0tXlcVkvCqpjpRdEakrvVu__7O7jYUvvo7c1UVpD61mqDEWKR Gmj10Ue8ZvVgW0TERVxvDzLY1.0s8CtzKt_pOeEdbIrdeIp0KVLuNvd; HttpOnly; SameSite=None; Secure; Path=/; Domain=t.co; Expires=Tue, 14 Jul 2026 20:04:45 GMT x-response-time: 11 origin-cf-ray: a1b2f77358fa9c18-IAD strict-transport-security: max-age=631138519; includeSubdomains x-served-by: t4_a cf-cache-status: DYNAMIC vary: accept-encoding cf-ray: a1b2f77358fa9c18-IAD