Active scanning in Burp Suite is fundamentally different from passive scanning because it modifies traffic to elicit responses, whereas passive scanning observes traffic without altering it.
Let’s see this in action. Imagine we’re analyzing a simple web application that echoes back user input.
First, the passive scanner. We’ll point Burp at http://test.local:8080/echo and send a request:
GET /echo?message=hello HTTP/1.1
Host: test.local:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
The passive scanner will observe this request and the corresponding response. If the response simply contains hello, the passive scanner flags it as potentially interesting, but it doesn’t do anything to cause that hello to appear. It’s like watching a conversation – you see what’s said, but you don’t contribute.
Now, the active scanner. We configure Burp to actively scan the /echo endpoint. When Burp sends a request, it doesn’t just send GET /echo?message=hello. Instead, it might try variations like:
GET /echo?message=' OR 1=1 -- HTTP/1.1
Host: test.local:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
... (rest of headers)
Or:
GET /echo?message=<script>alert('XSS')</script> HTTP/1.1
Host: test.local:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
... (rest of headers)
The active part is that Burp is injecting these payloads and waiting for a specific, anomalous response that indicates a vulnerability. It’s actively probing. If the application returns an error message containing SQL syntax, or if the <script>alert('XSS')</script> payload is reflected directly in the HTML, the active scanner flags a vulnerability. It’s like intentionally asking a provocative question to see if you get a reaction.
The core problem active scanning solves is finding vulnerabilities that are not evident from normal traffic analysis. Passive scanning can find things like missing security headers or exposed sensitive information in responses, but it won’t find SQL injection, cross-site scripting (XSS), or insecure direct object references (IDOR). These require injecting malicious-looking data and observing how the application handles it.
Here’s how it works internally: Burp maintains a library of attack payloads for various vulnerability types. When you initiate an active scan on a specific request, Burp iterates through these payloads, substitutes them into relevant parts of the request (like URL parameters, form fields, headers), and sends the modified request to the server. It then analyzes the response for indicators of success. For SQL injection, this might be an error message, a performance difference (time-based blind SQLi), or a change in content. For XSS, it’s often the payload appearing unescaped in the response.
The key levers you control in active scanning are the scope of the scan, the attack insertion points (which parts of the request Burp will inject into), and the speed/intensity of the scan. You can tell Burp to only scan specific URLs, to inject payloads only into parameters, or to try a very aggressive set of tests.
The most surprising thing is how much Burp’s active scanner relies on detecting deviations from expected behavior. It’s not just about sending a payload; it’s about observing how the application reacts to that payload in a way that deviates from how it would handle normal input. This often involves comparing responses from a "clean" request against the payload-injected request, looking for differences in status codes, content length, specific error messages, or even timing.
The next concept you’ll want to understand is how to configure Burp’s active scanner to avoid overwhelming your target system while still being effective.