Advanced HTTP Security Headers Analyzer
Security header audit, cookie inspection, tech fingerprinting, and compliance grading.
The HTTP Headers Analyzer fetches response headers from any URL and runs a structured security audit. It grades each security header, inspects cookie attributes, identifies server technology from header values, and produces an overall security grade.
Advance Headers Forensics
How to Use
Work through these steps in order. Use this tool for educational and ethical purposes only.
| 1 | Select HTTP Headers Analyzer from the tool navigation. |
| 2 | Enter the full target URL including the scheme (https://example.com). |
| 3 | Click Analyze Headers. The tool sends a server-side HEAD request to avoid CORS restrictions. |
| 4 | Review the Security Headers panel. Each header (CSP, HSTS, X-Frame-Options, etc.) receives a Pass, Warn, or Fail rating. |
| 5 | Check the Overall Security Grade (A through F) calculated from the weighted header score. |
| 6 | Review the Cookie Security panel showing each cookie’s Secure, HttpOnly, and SameSite attributes. |
| 7 | Check the Technology Fingerprint section for server software, frameworks, and CDN signatures found in header values. |
| 8 | Review CORS policy analysis: Access-Control-Allow-Origin, Access-Control-Allow-Methods, and credential support flags. |
What Are HTTP Security Headers?
Every time a browser requests a webpage, the server sends back two things: the visible content, and a set of HTTP headers that travel invisibly in the background. These headers carry instructions that govern how the browser handles what it receives.
Request headers come from the browser, telling the server things like accepted content types, preferred language, and session cookies. Response headers come from the server, instructing the browser on caching, content type, and security rules to enforce while rendering.
Security headers are a specific subset of response headers. They close the gap between what a browser can do and what it should do on a given site. Without them, browsers apply permissive defaults that attackers routinely exploit.
Header | Function |
|---|---|
Strict-Transport-Security | Forces HTTPS connections. Prevents protocol downgrade and man-in-the-middle attacks. |
Content-Security-Policy | Controls which scripts, styles, and resources the page can load. Blocks XSS and injection attacks. |
X-Frame-Options | Prevents the page from being embedded in an iframe. Stops clickjacking. |
X-Content-Type-Options | Stops the browser from guessing the MIME type. Prevents script execution from non-script files. |
Referrer-Policy | Controls how much URL data gets passed to third parties when a user clicks a link. |
Permissions-Policy | Restricts browser feature access (camera, microphone, geolocation) per origin. |
A site missing HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy earns a Security Grade of F. That’s not cosmetic. It means real attack vectors stay open for every visitor.
HTTP Header Leaks and What Attackers Do With Them
Before launching a targeted exploit, attackers run reconnaissance. HTTP headers are one of the richest free intelligence sources a server hands out, often without the site owner realizing it.
Server Banner Exposure
A Server header broadcasts the web server software in use. The tool flags this as Server Banner Exposure: LiteSpeed for recosint.com. An attacker now knows the server type without sending a single malicious packet and can immediately cross-reference known CVEs for LiteSpeed.
Technology Stack Exposure
The x-powered-by header is more dangerous. It exposes the backend language and exact runtime version. The raw headers for recosint.com show:
x-powered-by: PHP/8.3.19
That single line tells an attacker the site runs PHP 8.3.19. If a CVE exists for that version, they have a ready-made attack vector.
Neither header serves any functional purpose for a browser. They exist purely as debugging leftovers from development. In production, removing them costs nothing. Leaving them in hands attackers a head start.
Suppressing these headers takes one config change per platform:
- LiteSpeed / Apache: ServerTokens Prod and ServerSignature Off
- PHP (php.ini): expose_php = Off
- Nginx: server_tokens off;
Cache Header Leaks
Poorly configured cache headers can expose authenticated session data to shared caches. A Cache-Control: no-store directive on sensitive pages prevents this. Its absence is another form of exposure that typically goes unnoticed until an incident forces a review.
Hardening HTTP Headers
Adding headers is only half the job. Each header needs correct values. A misconfigured CSP that allows unsafe-inline is nearly as dangerous as no CSP at all.
HSTS
Strict-Transport-Security: max-age=31536000; includeSubDomains
max-age=31536000 sets a one-year enforcement window. includeSubDomains extends the rule to all subdomains. For maximum protection, add preload and submit the domain to the HSTS Preload List. HTTPS must already be working correctly before enabling HSTS, otherwise users will be locked out.
X-Frame-Options
X-Frame-Options: SAMEORIGIN
Allows the page to be framed only by pages on the same domain. Use DENY if the page should never appear in a frame. For more granular control, use CSP’s frame-ancestors directive instead.
X-Content-Type-Options
X-Content-Type-Options: nosniff
Tells the browser to respect the Content-Type header and never override it. A one-liner with no trade-offs.
Referrer-Policy
Referrer-Policy: strict-origin-when-cross-origin
Sends the full URL as the referrer for same-origin requests, but only the origin for cross-origin requests. Preserves analytics while keeping user paths from leaking to third-party domains.
Removing Server Identity Headers
Strip Server and X-Powered-By at the server or middleware level. They add no value for browsers and exist only as reconnaissance targets.
Secure Cookie Flags
Session and authentication cookies should always include:
- HttpOnly — blocks JavaScript from reading the cookie
- Secure — restricts the cookie to HTTPS connections
- SameSite=Strict or SameSite=Lax — prevents cross-site request forgery
Technical Details & Use Cases
HTTP security headers defend against a range of client-side attacks. The tool audits seven headers: Content-Security-Policy (XSS mitigation), Strict-Transport-Security (HSTS), X-Frame-Options (clickjacking), X-Content-Type-Options (MIME sniffing), Referrer-Policy (data leakage), Permissions-Policy (feature access), and Cache-Control (sensitive data caching).
Each header is checked for both presence and correct configuration. HSTS is evaluated for the max-age value (31536000 seconds minimum), the includeSubDomains flag, and the preload directive. CSP is checked for unsafe-inline and unsafe-eval, since either directive negates most of the policy’s protection.
Cookie analysis reads each Set-Cookie header for the Secure attribute (HTTPS-only), HttpOnly (blocks JavaScript access), and SameSite (CSRF mitigation: Strict, Lax, or None).
Technology fingerprinting reads Server, X-Powered-By, X-Generator, and Via headers. These expose web server type, application framework, and CDN provider, which attackers use to narrow their targeting.
Typical use cases: pre-launch security reviews, bug bounty reconnaissance, PCI-DSS compliance checks, and developer header configuration.
Pros & Cons
| Pros | Cons |
| ✓ Audits all seven critical security headers with Pass, Warn, and Fail detail | ✗ Uses a HEAD request only, so headers set dynamically on POST responses are not captured |
| ✓ Cookie attribute check covers Secure, HttpOnly, and SameSite in one pass | ✗ CSP analysis does not fully evaluate complex policy directives or nonce-based configurations |
| ✓ Technology fingerprinting shows what server information is being exposed to any visitor | ✗ Some WAFs block non-browser user agents, which can cause fetch failures |
Related Web Security & Privacy Modules
Frequently Asked Questions
What is an HTTP security header?
An HTTP security header is a response header sent by a web server that instructs the browser how to handle the page’s content. Headers like Strict-Transport-Security, Content-Security-Policy, and X-Frame-Options define rules that enforce HTTPS, block cross-site scripting, and prevent clickjacking.
Why does a missing HSTS header matter?
Without HSTS, the browser will accept an HTTP connection if one is offered, making the site vulnerable to SSL stripping and man-in-the-middle attacks. An attacker can intercept the initial unencrypted request before the user reaches the HTTPS version. HSTS eliminates this by instructing the browser to always use HTTPS, unconditionally.
What does a Security Grade F mean?
It means the site is missing multiple critical security headers. An F typically indicates that HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy are all absent, leaving the site exposed to several well-documented attack classes at once.
Is exposing a PHP version in HTTP headers actually risky?
Yes. Exposing the PHP version via x-powered-by (e.g., PHP/8.3.19) gives attackers a precise version string to check against known vulnerability databases. If a CVE exists for that version, they gain a confirmed attack vector before sending a single exploit packet. Setting expose_php = Off in php.ini removes this entirely at zero cost.
Does a "Present" status mean a header is correctly configured?
Not necessarily. A “Present” status confirms the header exists but does not validate its values. A Content-Security-Policy that allows unsafe-inline or unsafe-eval, for example, provides significantly weakened XSS protection. For full CSP validation, a dedicated policy analyzer is needed alongside this tool.
Recosint Intelligence Suite
For Business Inquiries, Sponsorship's & Partnerships
(Response Within 24 hours)
