Understanding Web Application Security Testing With Burp Suite

There's a tool sitting on the laptop of almost every professional penetration tester, bug bounty hunter, and security researcher in the world. It's called Burp Suite. It's been around since 2003. It's used every single day to find vulnerabilities in web applications — including, almost certainly, applications built by developers who have never heard of it.

Understanding how Burp Suite works isn't about learning to attack things. It's about understanding what an attacker sees when they look at your application from the outside. And that perspective — seeing your own app the way an attacker does — is genuinely one of the most useful shifts a web developer can make.

This post walks through the core features of Burp Suite, what attackers actually use them for, and what each one implies about things you should be checking in your own code.

What Burp Suite Actually Is

At its core, Burp Suite is an intercepting proxy. It sits between your browser and the internet, capturing every HTTP and HTTPS request your browser sends and every response the server returns. From there, it branches out into a full toolkit for analyzing, modifying, replaying, and fuzzing those requests.

The Community Edition is free. The Professional version costs money but adds automated scanning, more powerful fuzzing, and additional tools. Most of what we're covering here is available in the free version — which tells you something about how accessible web application testing has become.

Setup is straightforward: install Burp, configure your browser to use it as a proxy (127.0.0.1:8080), install Burp's CA certificate so it can intercept HTTPS traffic, and you're reading every request your browser makes in plain text.

The Proxy — Seeing Everything

The Proxy tab is where most sessions start. Every request flows through here before reaching the server. An attacker can pause any request, read it in full, modify any part of it — headers, parameters, body, cookies — and then forward the modified version to the server.

What this means in practice: any security check that relies on data sent from the browser is trivially bypassable. Hidden form fields, client-side validation, price values in POST requests, role flags in cookies — all of it can be edited before it reaches your server.

A classic example: an e-commerce checkout that includes the item price in the POST request.

POST /checkout HTTP/1.1
Host: yoursite.com
Content-Type: application/x-www-form-urlencoded

item_id=42&quantity=1&price=2999&user_id=1001

An attacker intercepts this in Burp, changes price=2999 to price=1, forwards it, and if your backend trusts that value — they just bought something for one cent.

The fix is obvious once you see it: never trust price, quantity calculations, or any security-relevant value that comes from the client. Recalculate everything server-side from your database.

<?php
// Wrong - trusting client price
$price = $_POST['price'];
processPayment($price);

// Right - look it up from your database
$stmt = $db->prepare("SELECT price FROM products WHERE id = ?");
$stmt->execute([$_POST['item_id']]);
$product = $stmt->fetch();
processPayment($product['price']);

Repeater — Replaying and Tweaking Requests

Once an attacker has captured an interesting request in the Proxy, they send it to the Repeater tab. Here they can modify specific parameters and resend the request as many times as they want, comparing responses side by side.

This is how manual SQL injection testing works. An attacker takes a request that includes a parameter — say, id=5 in a GET request — and starts modifying it:

GET /api/user?id=5         → normal response
GET /api/user?id=5'        → SQL error? Different response?
GET /api/user?id=5 OR 1=1  → returns all users?
GET /api/user?id=5; DROP TABLE users-- → server error?

Each variation tells them something about how your backend handles the input. A SQL error message is particularly useful — it confirms injection is possible and often reveals database structure. A response that takes noticeably longer on certain payloads suggests a time-based blind injection point.

Repeater is also how attackers test authentication logic. They capture a request that requires authentication, strip the session cookie, change the user ID, and see what happens. If the response includes another user's data — that's an IDOR (Insecure Direct Object Reference) vulnerability, and it's one of the most common findings in bug bounty programs.

// Vulnerable
GET /api/invoice?id=1042
// Returns invoice for user 1001 — but what if we request id=1043?
// If the server only checks "are you logged in" and not "does this belong to you" — data leak.

// Correct approach
$stmt = $db->prepare(
    "SELECT * FROM invoices WHERE id = ? AND user_id = ?"
);
$stmt->execute([$_GET['id'], $_SESSION['user_id']]);

Intruder — Automated Fuzzing

The Intruder tab takes a captured request, lets you mark specific parameters as injection points, and then fires a wordlist of payloads at them automatically. It's how attackers do brute force, credential stuffing, and parameter fuzzing at scale.

A login endpoint with no rate limiting and no lockout is trivially attacked with Intruder. The attacker marks the password field as the payload position, loads a wordlist of common passwords, and runs it. Burp sends thousands of requests and flags the ones that get a different response — typically a redirect or a success message instead of "invalid credentials."

This is exactly why rate limiting on authentication endpoints is non-negotiable. Even a basic implementation that locks out an IP after ten failed attempts in sixty seconds makes Intruder attacks impractical at any reasonable speed.

Intruder is also used for parameter discovery — finding hidden endpoints, undocumented API parameters, and admin paths by fuzzing URL segments against a wordlist of common names.

GET /admin         → 404
GET /administrator → 404
GET /admin-panel   → 302 (redirect to login!) — found something
GET /api/v2/users  → 200 — undocumented endpoint

This is why security through obscurity fails. Hidden endpoints are not protected endpoints. Anything accessible via HTTP is discoverable.

Scanner — Automated Vulnerability Detection

Burp Pro's Scanner crawls your application and automatically tests for common vulnerabilities — SQL injection, XSS, XXE, open redirects, path traversal, and more. It's not perfect and generates false positives, but it catches a lot of basic issues quickly.

The free version doesn't include automated scanning, but the workflow of manually browsing through an app while Burp passively analyzes traffic still surfaces many issues. Any request that includes user input gets flagged for manual testing.

What the scanner looks for gives you a useful checklist for your own code review:

• Any parameter reflected in the response without encoding — potential XSS
• Any parameter used in database queries without parameterization — potential SQLi
• Any file path constructed from user input — potential path traversal
• Any redirect that includes a URL from user input — potential open redirect
• Any XML parsing that accepts external entities — potential XXE

Decoder — Understanding Encoded Data

The Decoder tab converts between encoding formats — Base64, URL encoding, HTML entities, hex, and more. This sounds simple but it's how attackers analyze tokens, session identifiers, and any data that looks encoded.

A session token that decodes to user_id=1001&role=user&expires=1743811200 is a catastrophic design — the attacker just changes role=user to role=admin, re-encodes it, and replaces their session cookie. If your backend trusts that value without verifying a signature, they're now an admin.

This is why session data belongs server-side. A session token should be an opaque random string that maps to server-stored session data — not a container for the session data itself.

<?php
// Wrong - data in the token
$token = base64_encode(json_encode([
    'user_id' => $user_id,
    'role' => 'user'
]));

// Right - opaque token maps to server-side data
session_start();
$_SESSION['user_id'] = $user_id;
$_SESSION['role'] = 'user';
// PHP handles the secure session ID automatically

Testing Your Own App With Burp

Here's a practical routine for running Burp against your own application before shipping:

1. Set up the proxy and browse every page of your app normally. Log in, browse, submit forms, make purchases, change settings. Let Burp capture everything in the HTTP history.

2. Go through the history and identify every parameter. GET parameters, POST body fields, cookies, custom headers — anything that carries user-controlled data to your server is a potential injection point.

3. Send interesting requests to Repeater and test manually. Try SQL payloads on database parameters. Try script tags on anything reflected in the output. Try accessing other users' resources by changing IDs. Try submitting negative numbers, extremely large numbers, empty strings, and special characters.

4. Test authentication thoroughly. Try accessing authenticated pages without a session cookie. Try replacing your session cookie with a modified or corrupted value. Try accessing another user's resources with your valid session.

5. Check every response for information leakage. Error messages, stack traces, internal paths, database names, software versions in headers — all of this is useful to an attacker and none of it should be visible in production.

The Developer Takeaway

Burp Suite makes visible what was always true: HTTP is just text, and anyone between your browser and your server — or anyone with access to your browser — can read and modify it freely. Every security assumption that relies on the client sending honest data is a vulnerability waiting to be found.

The developers who build the most secure applications are usually the ones who've spent some time on the other side of this — watching their own requests flow through Burp, seeing what an attacker sees, and feeling the gap between "the browser sends this" and "the server should trust this."

Download Burp Community. Point it at a test environment of your own app. Spend an afternoon clicking through it. I'd be surprised if you don't find at least one thing worth fixing before the end of the session.

Next up we're going to look at how XSS attacks actually work in modern applications — why Content Security Policy helps, where it falls short, and how stored XSS can turn your own users into attack vectors. Coming soon.

— JSHook Team