After this lesson, you will be able to: Read and filter HTTP history, understand requests and responses in depth, set scope before an engagement, and map all endpoints and parameters of a target application.
HTTP history is the record of every request your browser made through Burp. This lesson teaches you to read it like a professional: filtering, understanding every part of a request and response, setting scope, and mapping an application's attack surface in a lab.
Every request flows through Proxy > HTTP history. On a real app that is a flood, so you filter: by host, method, status code, content type, and (most usefully) by scope. The filter bar at the top is your friend. Learning to narrow history to exactly the requests that matter is what makes triage fast.
A request has a method (GET, POST, PUT, DELETE), a path, query parameters, headers, and sometimes a body. Headers you will inspect constantly: Host, Cookie (session tokens), User-Agent, Content-Type (form data vs JSON vs multipart), and Authorization (Bearer tokens, API keys). The body carries submitted data. Every one of these is a place a vulnerability can hide and a thing you can modify in Repeater.
A response has a status code (200, 301, 401, 403, 404, 500), response headers (Set-Cookie, Content-Type, Location), and a body. The status code and length are quick signals: a different length or code for one input than another often reveals a vulnerability (different response for a valid vs invalid username, for instance). You will watch responses closely in every later lesson.
Scope defines the hosts you are testing. Set it before any engagement: right-click a target in the site map and Add to scope, then enable 'show only in-scope items' in history. This keeps you from sending traffic at out-of-scope hosts (a real concern in bug bounty, where out-of-scope testing voids your reward and can be illegal) and cuts noise. Use regex for wildcard scope when a program covers many subdomains.
Use a PortSwigger Web Security Academy lab.
1. Open any Web Security Academy lab and add its host to scope.
2. Browse the whole application normally (every link, every form) so Burp records the traffic.
3. In HTTP history (filtered to scope), list every endpoint you have seen.
4. For each endpoint, note every parameter (query, body, header, cookie) you can observe.
5. You now have the attack surface: the set of inputs a tester probes. This map is the starting point of every engagement.
Pick the best reason.
Not setting scope and drowning in third-party noise. Ignoring response length/status differences that reveal vulnerabilities. Missing parameters hidden in headers or cookies. Testing out-of-scope hosts in a bug bounty (a serious error). Browsing too little, so the site map misses endpoints. Forgetting that the map is the foundation: you cannot test what you have not discovered.
Sign in and purchase access to unlock this lesson.