HTTP Header Pentesting
A comprehensive guide for testing HTTP header vulnerabilities during web security assessments.
When to Use This Skill
Use this skill when:
- Testing web applications for header-based vulnerabilities
- Analyzing proxy configurations and header handling
- Investigating cache-related security issues
- Testing for HTTP request smuggling
- Bypassing security controls via header manipulation
- Auditing security headers on web applications
- Testing header name casing bypasses
- Any web pentesting task where HTTP headers are relevant
Quick Reference: Common Attack Vectors
IP Spoofing Headers
These headers can be used to spoof the client's IP address:
X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Forwarded: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
Client-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
Why this matters: Applications that trust these headers for authentication, rate limiting, or access control can be bypassed by injecting spoofed values.
URL Rewriting Headers
These headers can redirect or rewrite request paths:
X-Original-URL: /admin/console
X-Rewrite-URL: /admin/console
Why this matters: Some proxies and load balancers use these headers to determine the actual request path, potentially bypassing access controls.
Hop-by-Hop Headers
Hop-by-hop headers are processed by the current proxy, not forwarded end-to-end:
Connection: close, X-Forwarded-For
Why this matters: Malicious headers can be injected into the Connection header to make them appear as hop-by-hop, potentially bypassing security filters.
HTTP Request Smuggling
HTTP request smuggling occurs when there's a mismatch in how front-end and back-end servers interpret request boundaries.
Content-Length vs Transfer-Encoding
The most common smuggling technique involves conflicting headers:
Content-Length: 30
Transfer-Encoding: chunked
Why this matters: Different servers prioritize these headers differently. When a proxy and backend disagree on which header to trust, requests can be desynchronized, allowing attackers to inject requests or steal responses.
Expect Header Abuse
The Expect: 100-continue header can cause various issues:
Expect: 100-continue
Expect: y 100-continue
Potential issues:
- HEAD requests with bodies may keep connections open until timeout
- Servers may return random data or secret keys
- Can cause CL.0 or 0.CL desyncs if backend responds with 400/404 instead of 100
Why this matters: The Expect header is often poorly implemented, leading to request smuggling or information disclosure.
Cache Manipulation
Server Cache Headers
Monitor these response headers to understand caching behavior:
| Header | Purpose |
|---|---|
X-Cache |
Shows hit or miss status |
Cf-Cache-Status |
Cloudflare cache status |
Cache-Control |
Caching directives (e.g., public, max-age=1800) |
Vary |
Additional headers used as cache key |
Age |
Seconds since object was cached |
Server-Timing |
CDN cache status (e.g., cdn-cache; desc=HIT) |
Local Cache Headers
Clear-Site-Data: "cache", "cookies"
Expires: Wed, 21 Oct 2015 07:28:00 GMT
Pragma: no-cache
Warning: 110 anderson/1.3.37 "Response is stale"
Why this matters: Cache headers can be manipulated to poison caches, steal sensitive data, or bypass authentication.
Conditional Requests
If-Modified-Since: <date>
If-Unmodified-Since: <date>
If-Match: <etag>
If-None-Match: <etag>
Why this matters: These headers interact with Last-Modified and ETag to control caching. Misconfigurations can lead to cache poisoning or information disclosure.
Range Request Attacks
Range requests can be used for various attacks:
Range: bytes=80-100
Accept-Ranges: bytes
If-Range: <etag-or-date>
Attack vectors:
- Information disclosure: Combine
RangewithETagin HEAD requests to leak content hashes - XSS injection: Reflect arbitrary JavaScript through range responses
- Content manipulation: Request specific byte ranges to bypass filters
Example: A request with Range: bytes=20-20 and response ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" leaks the SHA1 of byte 20.
Why this matters: Range requests are often overlooked in security testing but can leak sensitive information or enable XSS.
Security Headers Audit
Content Security Policy (CSP)
CSP restricts resource loading and script execution:
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'
Why this matters: Missing or weak CSP allows XSS attacks. Test for bypasses in CSP configurations.
X-Content-Type-Options
Prevents MIME type sniffing:
X-Content-Type-Options: nosniff
Why this matters: Without this header, browsers may interpret files as different types, enabling XSS.
X-Frame-Options
Prevents clickjacking:
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
Why this matters: Missing or misconfigured X-Frame-Options allows pages to be embedded in iframes.
Cross-Origin Headers
Cross-Origin-Resource-Policy: same-origin
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin-allow-popups
Why this matters: These headers control cross-origin resource access. Misconfigurations can lead to data leaks or Spectre-like attacks.
HTTP Strict Transport Security (HSTS)
Forces HTTPS connections:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Why this matters: Without HSTS, users can be downgraded to HTTP, enabling MITM attacks.
Permissions-Policy
Controls browser feature access:
Permissions-Policy: geolocation=(), camera=(), microphone=()
Common directives:
accelerometer,camera,geolocation,gyroscope,magnetometermicrophone,payment,usb,fullscreenautoplay,clipboard-read,clipboard-write
Syntax values:
()- Disable entirely(self)- Same origin only*- All origins(self "https://example.com")- Same origin plus specified domain
Why this matters: Overly permissive policies allow attackers to abuse browser features through XSS or embedded iframes.
Header Name Casing Bypass
HTTP/1.1 defines header names as case-insensitive, but many applications perform case-sensitive comparisons.
How It Works
- Identify a header that is filtered or validated server-side
- Send the same header with different casing (e.g.,
CAmelExecCommandExecutableinstead ofCamelExecCommandExecutable) - The vulnerable check is skipped, but the downstream component accepts it
Example: Apache Camel RCE (CVE-2025-27636)
curl "http://<IP>/command-center" \
-H "CAmelExecCommandExecutable: ls" \
-H "CAmelExecCommandArgs: /"
Why this matters: Custom middleware, security filters, and business logic often compare header names case-sensitively, allowing bypasses.
Detection & Mitigation
- Normalize all header names to lowercase before comparisons
- Reject suspicious duplicates (e.g., both
Header:andHeAdEr:) - Use positive allow-lists enforced after canonicalization
- Protect management endpoints with authentication
Testing Methodology
Step 1: Reconnaissance
- Send requests with various header combinations
- Observe response headers for caching behavior
- Identify security headers present or missing
- Test for header reflection in responses
Step 2: Header Injection
- Try IP spoofing headers to bypass access controls
- Test URL rewriting headers for path traversal
- Inject hop-by-hop headers to bypass filters
- Test header name casing variations
Step 3: Cache Testing
- Send requests with different
Varyheader values - Test conditional request headers
- Attempt cache poisoning with manipulated headers
- Check for sensitive data in cached responses
Step 4: Request Smuggling
- Send conflicting
Content-LengthandTransfer-Encoding - Test
Expect: 100-continuevariations - Monitor for desync indicators (unexpected responses, timing anomalies)
- Attempt to inject requests or steal responses
Step 5: Security Header Audit
- Check for missing security headers
- Test CSP bypasses
- Verify X-Frame-Options effectiveness
- Audit Permissions-Policy configurations
- Test HSTS implementation
Tools and Resources
Wordlists
Testing Commands
Use the test-http-headers.sh script (see scripts/) to:
- Generate test requests with various header combinations
- Test for header-based vulnerabilities
- Audit security headers on target applications
Best Practices
- Always test in authorized environments only - Header manipulation can disrupt services
- Document findings clearly - Include request/response pairs for reproducibility
- Consider business logic - Header vulnerabilities often depend on application-specific behavior
- Test edge cases - Different casing, encoding, and header combinations
- Verify mitigations - Ensure fixes don't break legitimate functionality