Burp Suite Pro: Advanced Web App Security Testing
In 2023, attackers exploited a misconfigured authentication endpoint in a SaaS platform — a flaw that a single Burp Suite Pro active scan would have caught in under two minutes. The vulnerability? An IDOR (Insecure Direct Object Reference) hiding in plain sight behind a JSON parameter. If you’re still using Burp’s free tier or clicking through the UI without a strategy, you’re leaving critical bugs on the table.
\n\n
Active Scanning a Specific Endpoint
\n\n
Burp Scanner is not a \”launch and pray\” tool. Professionals target it surgically. Instead of scanning an entire application and drowning in noise, isolate the endpoints that handle sensitive logic: authentication, file uploads, account settings.
\n\n
Here’s the workflow. Proxy your browser through Burp (default listener: 127.0.0.1:8080), log in to the target app at https://staging.corpapp.internal, and navigate to the account profile page. In the HTTP history tab, right-click the POST request to /api/v2/user/update and choose Do active scan.
\n\n
Burp will inject payloads into every parameter. Within minutes you’ll see output like this in the Issue Activity panel:
\n\n
Issue: SQL Injection\nSeverity: High\nConfidence: Certain\nEndpoint: POST https://staging.corpapp.internal/api/v2/user/update\nParameter: user_id\nEvidence:\n Request: user_id=42'+AND+1=CAST((SELECT+version())+AS+INT)--\n Response: ERROR: invalid input syntax for type integer:\n \"PostgreSQL 14.2 on x86_64-pc-linux-gnu\"\n\n\n
That response is gold. The database threw a type-cast error, confirming the backend is PostgreSQL 14.2 and that the user_id parameter is unsanitized. An attacker pivots immediately to data extraction — enumerating tables, pulling credentials. As a defender, you now have a confirmed, high-confidence finding with exact reproduction steps. File it, replicate it manually to eliminate false positives, and escalate.
\n\n
Cracking Business Logic With Intruder
\n\n
Burp Intruder is Burp’s payload-delivery engine. It takes a single HTTP request and fires it hundreds or thousands of times with values you control. The free version throttles requests — Pro removes that limit entirely, which matters when you’re brute-forcing a rate-limited endpoint or fuzzing parameter ranges.
\n\n
Scenario: the same app has a coupon redemption endpoint. You suspect the coupon codes are sequential integers wrapped in Base64. Capture this request in Burp:
\n\n
POST /api/v2/coupon/redeem HTTP/2\nHost: staging.corpapp.internal\nAuthorization: Bearer eyJhbGci...truncated\nContent-Type: application/json\n\n{\"coupon_code\": \"MTAwMQ==\"}\n\n
MTAwMQ== is Base64 for 1001. Send this request to Intruder. Highlight the Base64 value, add it as a payload position (the § markers). Now configure a payload processor:
\n\n
- \n
- Set payload type to Numbers, range 1000–1200, step 1.
- Add a payload processing rule: Encode → Base64-encode.
- Set the attack type to Sniper.
- Start the attack.
\n
\n
\n
\n
\n\n
Sort the results by HTTP status code. You’ll see something like:
\n\n
# Payload Status Length Comment\n1 MTAwMA== 404 212\n2 MTAwMQ== 200 389 \"coupon_redeemed\": true\n3 MTAwMg== 200 389 \"coupon_redeemed\": true\n4 MTAwMw== 403 201\n5 MTAwNA== 200 389 \"coupon_redeemed\": true\n...
\n\n
Three valid, unredeemed coupons discovered — all belonging to other accounts. This is a textbook IDOR. The app validates that the coupon exists but never checks whether it belongs to the authenticated user. An attacker walks away with free credits or discounts at scale. Your next move as a pentester: document the affected coupon ID range, calculate business impact (if codes are $10 each and 50 are valid, that’s $500 in exposed value), and report it as High severity.
\n\n
Turbo-Charging Repeater With Match-and-Replace
\n\n
Repeater is where you manually verify and escalate findings. One underused Pro feature: Match and Replace rules under Proxy settings. These auto-modify requests or responses in real time — without you editing them manually every single time.
\n\n
Example: the app enforces a role check via a response header X-User-Role: viewer. You want to test whether the frontend trusts this header blindly. Set a Match and Replace rule:
\n\n
- \n
- Type: Response header
- Match:
X-User-Role: viewer - Replace:
X-User-Role: admin
\n
\n
\n
\n\n
Now every response flowing through Burp replaces that header automatically. Reload the app in your browser. If the admin panel suddenly appears, the application is making trust decisions client-side — a critical authorization flaw. You just confirmed it without writing a single line of code.
\n\n
What To Do Now
\n\n
Open Burp Suite Pro right now and navigate to Proxy → HTTP History on any app you’re currently testing. Find the first POST request that touches user data. Right-click it, send it to Intruder, and add a payload position around any numeric ID parameter. Run a simple numbers payload from 1 to 50. If any response returns data that isn’t yours — you just found an IDOR. That single habit, applied consistently, catches more real vulnerabilities than any automated full-site scan.
