The first time I opened Burp Suite I was overwhelmed — dozens of tabs, none obvious. Months later I use maybe five features for 90% of testing. Here's that minimal workflow.
> Only test applications you own or are explicitly authorized to test. Everything below assumes a lab or an in-scope engagement.
1. Proxy: See Everything
The foundation. Point your browser through Burp's proxy and every request flows through it. Browse the app normally first — login, key features — to populate the Target → Site map. You can't test what you haven't seen.
2. Target: Define Scope
Add the target domain to scope and filter everything else out. This keeps the noise down and — importantly — stops you from accidentally sending traffic to out-of-scope hosts.
3. Repeater: The Workhorse
Send any interesting request to Repeater and modify it by hand:
GET /api/orders/1043 HTTP/1.1
Host: target.test
Cookie: session=...
Change 1043 to 1044. Does it return someone else's order? That's an IDOR, and Repeater is how you confirm it one request at a time.
4. Intruder: Automate the Boring Part
When you need to try many values — fuzzing an ID range, testing a parameter against a wordlist — Intruder automates it. Watch the response length and status columns; an outlier usually means you found something.
5. Decoder: Make Sense of Encoding
Tokens and parameters are often Base64, URL-encoded, or hex. Decoder unwraps them so you can see what's actually inside — sometimes a Base64 "token" is just a user ID you can change.
The Mindset Matters More Than the Tool
Burp doesn't find bugs — it lets you find them by making requests editable. The skill is asking "what happens if I change this value to one I shouldn't be allowed to use?" Burp just makes asking that question fast.