Overview
HTTP headers carry metadata on every request and response, and many are central to web security — from session cookies to the security headers that harden the browser. This lesson focuses on the headers that matter most for security.
Learning objectives
- Explain the role of request and response headers.
- Identify security-relevant headers.
- Recognize how headers are both defenses and attack targets.
Core concept
Headers are key/value metadata. Security-relevant ones include:
- Request:
Host(target site),Cookie(session state),Authorization(credentials),User-Agent,Referer. - Response:
Set-Cookie(withHttpOnly/Secure/SameSite),Location(redirects), and security headers likeContent-Security-Policy,Strict-Transport-Security,X-Content-Type-Options, and framing controls.
Headers are both a defense mechanism (security headers) and an attack target (attacker-controlled request headers).
How it works
Response security headers instruct the browser to behave more safely — enforcing HTTPS (HSTS), restricting resource loading (CSP), preventing MIME sniffing, and blocking framing (clickjacking). Cookie attributes protect sessions. On the request side, headers like Host, Cookie, and Authorization are client-controlled, so the server must never blindly trust them — for instance, trusting a spoofable Host header or an X-Forwarded-For for security decisions can be exploited. Headers therefore appear on both sides of the security equation.
Practical example
A hardened response might include Strict-Transport-Security, Content-Security-Policy: default-src 'self', X-Content-Type-Options: nosniff, and Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax. Together they force HTTPS, restrict scripts, block MIME sniffing, and protect the session cookie. Conversely, a server that decides "is this an internal admin request?" based solely on a client-supplied header can be tricked by an attacker who simply sets that header.
Cybersecurity relevance
Headers are one of the most common areas of web assessment. Missing security headers (no CSP/HSTS, cookies without protective flags) are frequent findings that increase exposure to XSS, session theft, downgrade, and clickjacking — the Security Headers module covers these in depth. On the offensive side, manipulating request headers (Host, Referer, forwarded-for, Authorization) probes for trust mistakes. Reading and setting headers correctly is fundamental to both defense and testing.
Common mistakes
- Shipping without security headers, leaving easy, high-impact gaps.
- Trusting client-controlled request headers (
Host,X-Forwarded-For) for security decisions. - Setting session cookies without
HttpOnly/Secure/SameSite.
Key takeaways
- Headers are metadata on requests and responses; security-relevant ones include Cookie/Authorization/Host (request) and Set-Cookie plus security headers like CSP and HSTS (response).
- Response security headers harden the browser; request headers are client-controlled and must not be blindly trusted.
- Missing security headers and trusting spoofable request headers are common findings; correct header handling is core to defense and testing.
Check your understanding
- Name two response security headers and what each protects against.
- Why is it dangerous to make a security decision based on a client-supplied header like
HostorX-Forwarded-For?

