Burp Suite Beginner Workflow for Web Pentest

Burp Suite is one of the most common tools used in web application security testing.

Beginners often learn Burp as an intercepting proxy: open browser, intercept request, modify something, send it forward.

That is only the first layer.

A better workflow treats Burp as a structured testing workspace:

Browser traffic -> Proxy history -> Scope -> Repeater -> Notes -> Evidence -> Report

Image: Type: Context. Mô tả: “A simple workflow diagram showing Browser, Burp Proxy, HTTP history, Repeater, Intruder, Logger, and final report evidence.” caption: “A clean Burp workflow turns raw traffic into reproducible security findings.”

Context

During a web pentest, Burp helps you observe, replay, modify, compare, and document HTTP traffic.

The core beginner tools are:

  • Browser and proxy setup
  • Target scope
  • Proxy HTTP history
  • Intercept
  • Repeater
  • Intruder
  • Decoder
  • Comparer
  • Logger
  • Notes and issue evidence

You do not need to use every feature at once. The goal is to build a repeatable workflow.

Step 1: Configure Browser and Proxy

Start by routing browser traffic through Burp.

Basic setup:

  1. Open Burp Suite.
  2. Use Burp’s embedded browser, or configure your browser proxy to Burp.
  3. Install the Burp CA certificate if testing HTTPS traffic with an external browser.
  4. Confirm traffic appears in Proxy history.

Do not start testing until you can see the traffic clearly.

If you cannot see the request, you cannot reason about the application properly.

Step 2: Define Scope

Scope prevents noise.

Set the target application domain as in scope.

Example:

https://app.example.com
https://api.example.com

Then configure Burp to show or highlight only in-scope traffic.

This matters because modern websites load many third-party resources: analytics scripts, fonts, CDNs, ads, identity providers, payment gateways, and support widgets.

A clean scope helps you focus on assets you are authorized to test.

Image: Type: Test case. Mô tả: “A Burp Target scope screen showing only app.example.com and api.example.com as in-scope assets.” caption: “Scope discipline keeps testing focused and legally clean.”

Step 3: Browse Normally First

Before attacking anything, use the application like a normal user.

Map:

  • Login
  • Registration
  • Password reset
  • Profile update
  • Search
  • File upload
  • Account settings
  • Billing
  • Admin panel
  • API calls
  • Logout

This creates natural traffic in Proxy history.

Do not rush into payloads. First understand how the application is supposed to work.

Step 4: Use Proxy History as Your Source of Truth

Proxy history is where you start pattern recognition.

Look for:

  • Interesting parameters
  • Object IDs
  • Role or permission indicators
  • JSON request bodies
  • Hidden API endpoints
  • File upload endpoints
  • Redirect parameters
  • Token values
  • Cookies
  • Custom headers
  • GraphQL requests
  • Different responses for different users

Example patterns:

GET /api/v1/invoices/1001
POST /api/v1/users/123/role
GET /download?file=report.pdf
POST /api/v1/reset-password

Each request is a clue.

A pentester’s skill is turning traffic into hypotheses.

Step 5: Send Interesting Requests to Repeater

Repeater is where manual testing becomes controlled.

Use Repeater to:

  • Modify one parameter at a time
  • Replay requests safely
  • Compare responses
  • Test access control
  • Test input handling
  • Validate assumptions
  • Build reproduction steps

Good Repeater workflow:

Original request -> duplicate tab -> change one variable -> observe response -> document result

Avoid changing too many things at once. If the response changes, you need to know which change caused it.

Step 6: Use Multiple Test Accounts

For access control testing, one account is not enough.

Use at least two test users when allowed:

User A -> owns object 1001
User B -> owns object 2001
Admin -> has privileged actions

Then test whether User A can access User B’s objects.

Example workflow:

Login as User A -> capture request for User A object
Login as User B -> capture request for User B object
Replay User B object request using User A session
Expected result: 403 Forbidden or equivalent denial

This is essential for IDOR, BOLA, and broken access control testing.

Image: Type: Test case. Mô tả: “Two Burp Repeater tabs comparing requests from User A and User B to test whether object-level authorization is enforced.” caption: “Access control testing requires comparing behavior across users and roles.”

Step 7: Use Intruder Carefully

Intruder can automate repeated request variations.

Beginner-safe use cases:

  • Checking a short list of known object IDs from test accounts
  • Testing a small wordlist in a lab
  • Comparing response lengths
  • Testing predictable numeric parameters in an authorized environment

Do not use Intruder for high-volume brute-force or aggressive scanning unless the engagement explicitly allows it.

In professional work, rate limits, scope, and authorization matter more than tool capability.

Step 8: Use Decoder and Comparer

Decoder helps inspect encoded values:

  • Base64
  • URL encoding
  • HTML encoding
  • JWT segments
  • Hex values

Comparer helps compare responses:

  • User A vs User B
  • Valid token vs invalid token
  • Allowed role vs denied role
  • Before and after modifying a parameter

These tools are simple but useful for understanding subtle differences.

Step 9: Take Notes While Testing

Do not wait until the end to write notes.

For each interesting request, record:

  • Endpoint
  • User role
  • Original behavior
  • Modified request
  • Observed response
  • Security assumption
  • Evidence screenshot
  • Impact hypothesis
  • Remediation idea

Example note:

Endpoint: GET /api/v1/invoices/{id}
User: regular user
Observation: invoice ID is numeric
Test: User A requested User B invoice ID using User A token
Result: API returned invoice data
Hypothesis: BOLA / IDOR
Impact: unauthorized invoice disclosure

Good notes reduce report writing time.

Step 10: Build Report Evidence

For every confirmed finding, preserve:

  • Original request
  • Modified request
  • Response showing impact
  • Account context
  • Timestamp
  • Screenshot when useful
  • Clear reproduction steps

Evidence must be enough for the developer to reproduce the issue.

A finding without reproducible evidence becomes a conversation. A finding with clean evidence becomes an engineering task.

Beginner Workflow Summary

[ ] Configure browser and proxy
[ ] Confirm HTTPS traffic is visible
[ ] Define target scope
[ ] Browse the app normally
[ ] Review Proxy history
[ ] Identify interesting requests
[ ] Send requests to Repeater
[ ] Modify one variable at a time
[ ] Use multiple test accounts for access control
[ ] Use Intruder only when appropriate and allowed
[ ] Take notes during testing
[ ] Save evidence for the report

Common Beginner Mistakes

Mistake 1: Intercepting Everything

Leaving intercept on all the time can slow testing and create confusion.

Use intercept when needed. Use Proxy history for most review work.

Mistake 2: Testing Without Scope

Without scope, Burp captures too much unrelated traffic.

Scope first. Test second.

Mistake 3: Payload First, Context Later

Payloads are not a methodology.

Understand the feature, role, data flow, and trust boundary before testing input.

Mistake 4: Not Saving Evidence

If you cannot reproduce the issue later, you may lose the finding.

Save clean requests and responses while testing.

References

CTA

KevinSec can help teams perform structured manual web pentesting using reproducible workflows, clean evidence, and business-focused reporting. If your application needs more than a scanner output, a manual Burp-based review is a strong starting point.