headers

Overview

After the request line, every HTTP message carries a set of headers: name-value pairs that describe the request or response and control how each side behaves. Many HTTP challenges are solved by reading a header the server sends back, or by setting a header the developer trusted a little too much. This lesson explains what headers are, the common ones you will meet, and why they are such a rich source of challenge behavior — all in an authorized, isolated setting.

Learning objectives

• Explain what HTTP headers are and where they appear in a request and response.
• Recognize common request and response headers and what they do.
• Describe why headers are both a source of information and a place developers place misplaced trust.

Core concept

An HTTP header is a Name: Value line that carries metadata about the message — who is asking, what formats are acceptable, how long to cache, what kind of content is being returned, and so on. Headers appear in both requests (sent by the client) and responses (sent by the server), after the start line and before the body. They are just text you can read and, on the request side, freely set with a request tool. Because servers frequently make decisions based on header values, a header is often the key that a challenge turns on.

How it works

Some common request headers:

• Host — Which site the request is for (important when one server hosts many).
• User-Agent — Identifies the client software; some apps change behavior based on it.
• Accept — Which content types the client wants back (e.g. application/json).
• Cookie — Carries stored values such as a session identifier (covered in its own lesson).
• Authorization — Carries credentials or a token.
• Referer — The page the request came from.
• X-Forwarded-For — Added by proxies to record the original client address; sometimes trusted by apps.

Some common response headers:

• Content-Type — The format of the body (e.g. text/html).
• Set-Cookie — Instructs the client to store a cookie.
• Location — The target of a redirect.
• Server — Software the server chooses to advertise.
• Cache-Control — How the response may be cached.

Because request headers are fully client-controlled, an application that makes a security or logic decision based on one — trusting X-Forwarded-For as your "real IP", or serving a hidden view when it sees a particular User-Agent — can be steered by simply setting that header yourself.

Practical example

A challenge page says "access denied — internal users only." Inspecting the response, you notice nothing useful, so you look at how access might be decided. You add the header X-Forwarded-For: 127.0.0.1 to your request, mimicking a request that appears to originate locally. The application, which naively trusted that header to identify internal traffic, now serves the internal page and reveals the flag. Nothing was broken; the app simply trusted a value the client controls. In another challenge, the answer is hiding in plain sight inside a custom response header that the browser never displays but a request tool shows you directly.

Cybersecurity relevance

Headers matter on both sides of security work. On the offensive side of an authorized assessment, headers are a first place to look: response headers can leak software versions or debug information, and request headers are a common spot where developers place unwarranted trust (client IP headers, Host-based routing, User-Agent checks). On the defensive side, headers are also where important protections live — for example, headers that instruct browsers to enforce HTTPS or restrict content. Understanding that request headers are attacker-controllable and must be validated, never trusted blindly, is a core web-security lesson.

Common mistakes

• Assuming headers are set by the browser and cannot change — any request header can be set arbitrarily with a request tool.
• Only reading the body and ignoring response headers, where hints, tokens, or version leaks often sit.
• Trusting client-supplied headers like X-Forwarded-For or User-Agent for security decisions (a developer mistake challenges love to exploit).

Key takeaways

• Headers are Name: Value metadata lines in both requests and responses, sitting between the start line and the body.
• Common request headers include Host, User-Agent, Accept, Cookie, Authorization, and X-Forwarded-For; common response headers include Content-Type, Set-Cookie, Location, and Server.
• Request headers are client-controlled, so applications must validate rather than trust them — and challenges frequently hinge on reading or setting a single header.

Check your understanding

• Why is it a mistake for an application to make an access decision based on the X-Forwarded-For request header?
• Name two response headers and describe what information each one gives you when analyzing a target.