HTTP Header Diff

Compare HTTP response headers between two different URLs to identify differences in security configurations, caching policies, or server settings.

Evidence ASSESSED

Checked against: Response headers from both URLs, compared field by field

RED TEAM 0 findings BLUE TEAM control did not hold

Use Cases for Header Comparison

Comparing headers is essential for debugging and security auditing:

Environment Parity: Ensure your staging and production environments have identical security headers (CSP, HSTS).
Cache Debugging: Verify how different CDN edge locations or origins are handling Cache-Control or ETag headers.
Regression Testing: Check if a recent deployment inadvertently changed server information or compression settings.
Competitor Analysis: Observe differences in server technologies or security postures between your site and others.

Our HTTP Header Diff fetches two URLs and compares their response headers side by side, highlighting every difference. Use it to find configuration drift between environments, servers behind a load balancer, or before and after a deployment.

What is a Header Diff?

A header diff compares the HTTP response headers returned by two URLs and shows where they differ.

The value is in what headers reveal. Security headers, caching directives, cookie attributes, CORS policy and server identification are all configured independently, and all of them drift. A staging environment and production are supposed to be equivalent; a comparison frequently shows they are not.

Differences fall into a few categories. Some are expected — hostnames, timestamps, request identifiers. Some are benign but worth knowing about. And some are the reason the comparison was worth running: a security header present in one environment and absent in the other, or a caching directive that differs in a way nobody intended.

Compares response headers between two URLs
Headers are configured independently and drift over time
Reveals differences between staging and production
Exposes inconsistency between servers behind a load balancer
Some differences are expected; the interesting ones are not

Why Comparing Headers Matters

Configuration drift is invisible until something breaks. A security header configured in production but missing from a new server added to the pool means a proportion of requests are unprotected, and nothing reports it — the site works, the tests pass, and the gap persists until someone looks.

The staging-to-production comparison is equally valuable in the other direction. Testing security headers in staging proves nothing if production is configured differently, and discovering that mismatch after a deployment is considerably more expensive than discovering it before.

Drift between servers leaves a proportion of requests unprotected
Staging testing is meaningless if production differs
Deployment changes to headers are easy to make accidentally
Caching differences cause intermittent, hard-to-reproduce bugs
Nothing reports a missing header — the site simply works

How This Header Diff Works

The tool fetches both URLs and compares their response headers field by field.

Validates both URL inputs against format and SSRF safety checks
Issues an HTTP request to each URL
Captures the complete response headers from both
Compares them field by field, noting presence and value differences
Presents the results side by side with differences highlighted

How to Use the Header Diff

Enter the two URLs you want to compare
Run the comparison to fetch both responses
Review the differences, ignoring expected ones such as hostnames and timestamps
Focus on security headers present in one response and absent in the other
Check caching and cookie directives, which commonly drift

Understanding Your Header Comparison

Differences fall into categories worth treating differently:

Field / Value	Meaning
`Security header missing`	A header such as Strict-Transport-Security or Content-Security-Policy present in one response and absent in the other. Usually the most important finding.
`CSP value differs`	Both have a policy but they permit different sources. A more permissive policy on one environment undermines the protection the stricter one provides.
`Cache-Control differs`	Different caching behaviour between environments causes intermittent bugs that reproduce in one place and not the other.
`Cookie attributes`	Secure, HttpOnly and SameSite flags differing between responses. A cookie missing Secure in one environment can be transmitted over plaintext.
`Server identification`	Different server software or versions, indicating the two are not running the same stack. Sometimes intentional, often not.
`CORS policy differs`	Different Access-Control-Allow-Origin values. A permissive setting left in one environment is a genuine vulnerability.
`Expected differences`	Hostnames, dates, request identifiers and ETags will always differ. These are noise rather than findings.

Common Problems & How to Fix Them

Testing proved the headers work in an environment that is not the one serving users.

Set security headers at the reverse proxy, load balancer or CDN rather than in per-environment application configuration. That way a single configuration applies everywhere and cannot drift between environments.

A proportion of requests are being served with a different configuration, which makes the resulting bugs intermittent and extremely hard to reproduce.

Compare each backend individually by addressing them directly. The cause is usually a server added to the pool without the full configuration, or a deployment that did not reach every node. Use configuration management so all nodes are provisioned identically.

Permissive CORS added for development convenience frequently reaches production, where it becomes a real vulnerability allowing other sites to read authenticated responses.

Use environment-specific configuration so the development setting cannot become the production default, and verify the production policy explicitly rather than assuming it inherited the right value.

A session cookie missing Secure can be transmitted over plaintext; one missing HttpOnly is readable by script; one missing SameSite is more exposed to cross-site request forgery.

Set these attributes centrally in your framework session configuration rather than per environment, so they cannot differ between deployments.

A configuration change altered headers as a side effect, which is easy to do and easy to miss.

Compare against a pre-deployment capture as a routine post-deployment check. Better still, add an automated test asserting the expected security headers are present, so a regression fails the build rather than reaching production.

Best Practices

Compare staging against production before every significant release
Set security headers at the edge so they apply uniformly
Compare each backend individually when servers sit behind a load balancer
Capture headers before and after deployment as a routine check
Add automated tests asserting expected security headers
Use configuration management so nodes are provisioned identically
Ignore expected differences such as timestamps and request identifiers

Security Recommendations

Treat a security header present in one environment and absent in another as a production gap, not a staging curiosity
Check CORS policy differences carefully, since permissive development settings reaching production is a common and serious pattern
Verify cookie Secure, HttpOnly and SameSite attributes are consistent everywhere
Confirm version disclosure is suppressed in production even if it is left on in development
Compare after infrastructure changes as well as code deployments, since header configuration often lives outside the application
Automate the check rather than relying on someone remembering to run it

Frequently Asked Questions

Comparing the response headers of two URLs to find configuration drift — between staging and production, between servers behind a load balancer, or before and after a deployment.

Security headers present in one response and missing from the other, differing CORS policies, and inconsistent cookie security attributes. These represent real gaps rather than cosmetic variation.

Hostnames, dates, request identifiers, ETags and content lengths will always differ. These are noise. The interesting differences are in headers that should be configured identically.

Usually a node added to the pool without the full configuration, or a deployment that did not reach every server. The result is that a proportion of requests get different behaviour, which makes bugs intermittent and hard to reproduce.

Set security headers at the reverse proxy, load balancer or CDN so one configuration applies everywhere. Use configuration management for consistent provisioning, and add automated tests asserting the expected headers are present.

Security headers, yes. Some differences are legitimate — staging may add noindex directives or debugging headers — but every security-relevant header should match, or your staging testing does not tell you about production.

Address each backend directly by IP with the correct Host header, bypassing the balancer. Comparing through the balancer gives you whichever node happened to answer, which will not reveal inconsistency reliably.