This is an older essay or practical note. Its reference date is retained from the original entry; use current vendor guidance for product versions and security updates.
Good application testing starts with understanding a request, making a controlled change, and checking what the response actually proves. Burp helps connect that reasoning to reproducible evidence.
Technical notes checked against PortSwigger's documentation on 6 October 2026. The original reference date is retained above.
Map the application through Proxy
Use an agreed test scope, test accounts, and a controlled environment. Burp's built-in browser sends its traffic through Proxy, which can inspect and modify requests and responses. Review HTTP history as you navigate the application's workflows; intercept individual requests when a specific change is useful. PortSwigger's Proxy documentation.
Use Repeater to test a hypothesis
Repeater lets you edit and resend messages, inspect responses, and manually verify scanner findings. Establish a baseline, change one relevant input, and compare the resulting behaviour. Preserve the request, account context, and response that demonstrate the result. PortSwigger's Repeater documentation.
For example, in an authorised lab, two test accounts can help check whether a resource is limited to its owner. A changed response length alone is not a confirmed access-control flaw; verify the returned resource and the expected permission.
Choose the right Intruder pattern
Intruder assigns payloads to marked positions according to an attack type. These patterns behave differently:
- Sniper: One payload set, applied to each selected position in turn. Multiple positions are supported; they are tested individually.
- Battering ram: One payload set, with the same payload inserted into all selected positions at once.
- Pitchfork: A different set for each position, advancing the sets together. The shortest set limits the request count.
- Cluster bomb: A different set for each position, trying all combinations. Request counts can grow rapidly.
Review the expected request count and resource limits before running a test. PortSwigger's attack-type reference.
Separate crawling from auditing
Burp Scanner's crawl phase discovers application content and navigation paths. Its audit phase analyses traffic and behaviour for security issues. Scope, authentication, and reachable workflows affect what it can assess. Review discovered content and scan errors before assuming an automated run covered the application. PortSwigger's Scanner overview.
Interpret Collaborator evidence carefully
Collaborator detects out-of-band interactions that may not appear in an HTTP response. Burp supplies a unique domain payload and polls for interactions. Its server supports DNS, HTTP/HTTPS, and SMTP/SMTPS. Collaborator overview; server services.
A DNS interaction establishes that a lookup reached the service; it does not, by itself, prove arbitrary command execution. Correlate the interaction with the exact request, timing, protocol, and application behaviour. State the demonstrated impact and the remaining uncertainty.
Make the finding useful to a developer
Record the affected endpoint, test prerequisites, minimal reproduction, observed impact, and suggested fix. Keep sensitive tokens out of the report. Retest the same case after the change, and document which roles or workflows still need assessment.