Crawling and Scanning
Map every page and parameter, and know when the active scanner is safe to unleash.
What you will learn
- -Build a site map by browsing and set a target scope
- -Tell passive scanning apart from active scanning
- -Understand why the active scanner is a loud, authorization-gated tool
Before you attack an app you need its shape: every page, every , every that takes input. Burp keeps that picture under Target > Site map, a tree of and paths on the left with the requests and responses on the right.
Fill the map by browsing
In Community there's one way to populate it: you browse. Click through the app with interception off, and every request drops into the tree, sorted by host and path. Hit the links, submit the forms, in, exercise every feature you can find. Burp only knows about what your browser actually touched, so a checkout flow you never walked, or an admin page you never opened, stays invisible. Browse thoroughly.
Pro adds an automated crawler under Dashboard > New scan > Crawl that follows links for you. It's useful, but it never fully replaces walking the app by hand, because a crawler can't guess its way through a five-step checkout or a form that needs a valid coupon code.
Draw the fence first: scope
Set your before anything else, under Target > Scope settings. Add the target host, then turn on "show only in-scope items". Now Burp stops logging every CDN, ad , font host, and your browser fires on the side. You a clean history, and you stop yourself from accidentally aiming a tool at a you were never authorized to touch.
A tight scope keeps tooling from wandering off-target. When you later right-click a request and pick a scan or an Intruder run, an in-scope filter is the difference between hitting the 's app and hitting their payment processor by mistake.
Passive versus active scanning
These are not the same thing, and conflating them is how people cause outages.
Passive scanning only reads traffic that already passed through Burp. It flags missing security , without HttpOnly, values reflected back into responses, that class of thing. It sends nothing extra, so it's safe to leave running on in-scope traffic all day.
Active scanning is a different animal. It fires its own crafted requests: injection , malformed inputs, probes built to trigger errors. It submits forms, hammers parameters, and as a side effect it can create records, delete data, send emails, or lock accounts. It is loud, aggressive, and it announces itself to any monitoring the target has.
Community has passive checks and manual tooling only, no one-click active scan. Even on Pro, the active scanner has caused real damage: databases filled with junk rows, -reset floods, bans that locked the whole testing team out. Point it at a staging copy when one exists, scope it tight, and run it off-hours.
Scan like someone who has to explain it later
to test is not authorization to break production. Tell the client before you start an active scan, agree a window, and know how to stop it fast. The site map and passive findings will already hand you most of the low-hanging fruit; the manual work in Repeater and Intruder is where the interesting bugs actually get confirmed.
Crawling and active scanning both generate traffic that hits the target hard. Only run them against systems you have explicit, written permission to test.
Which statement is true of passive scanning in Burp?