Web Hacking 101 with Burp Suite

Web testing is mostly about watching the conversation between a browser and a server, then asking “what happens if I change this?” Burp Suite Community Edition is free and is the standard tool for that conversation.

Practice against your own Juice Shop or DVWA container, or the free PortSwigger Web Security Academy labs.

Step 1: Use Burp’s built-in browser

Old guides have you install certificates and configure proxies by hand. You don’t need to anymore.

1. Launch Burp, create a temporary project, and use the defaults.
2. Go to Proxy → Intercept and click Open browser.

That Chromium window is already proxied through Burp and trusts its certificate, so HTTPS just works.

Step 2: Set your scope first

Before you click anything, open Target → Scope and add only your target, for example http://localhost:3000. Then, in Proxy → HTTP history, filter to show only in-scope items.

This keeps background noise like browser telemetry and CDNs out of your history. On a real engagement it also stops you from testing something you aren’t authorized to touch.

Step 3: Read a request

Turn Intercept off, browse the target, and look at HTTP history. Click any request:

POST /rest/user/login HTTP/1.1
Host: localhost:3000
Content-Type: application/json
Cookie: language=en; welcomebanner_status=dismiss

{"email":"[email protected]","password":"hunter2"}

Each part is something the client controls:

Part	Why you care
Method and path	Hidden endpoints and unusual methods show up here first
Headers	Host, Origin, X-Forwarded-For, and custom headers all affect server logic
Cookies	Session tokens, feature flags, sometimes role information
Body	Every parameter is input the server has to validate

The core lesson of web security: the browser is just a suggestion. Anything the client sends can be changed.

Step 4: Repeater is where the work happens

Right-click a request and choose Send to Repeater (Ctrl+R). Now you can edit and resend it as many times as you like and compare responses side by side.

A good first exercise is to change one thing at a time and note what changes in the response:

• Remove a cookie. Does the endpoint still respond the same way?
• Change a numeric ID in the path to a neighbouring number. Do you see someone else’s data? That’s an IDOR (insecure direct object reference), and it’s one of the most common real-world bugs.
• Change the request method. Do PUT or DELETE behave differently from what the UI implies?
• Send an unexpected type, such as a string where a number belongs. Verbose error messages leak frameworks, file paths, and query structure.

Step 5: Map the OWASP Top 10 to what you see

Category	What it looks like in Burp
Broken access control	Changing an ID or role returns data you shouldn’t see
Injection	Input changes how a query or command is built, often revealed by errors
Cross-site scripting	Input is reflected into HTML without encoding
Security misconfiguration	Debug pages, default credentials, verbose stack traces
Authentication failures	No rate limiting on login, predictable reset tokens

Each of these has a free, guided lab track in the PortSwigger Academy, with a deliberately vulnerable app and the solution. Work through the Apprentice labs in each category before anything else.

Tricks most beginners miss

• Copy as cURL. In browser devtools, right-click any network request and choose Copy as cURL. Now you can replay it from the terminal or a script.
• Search everything. Burp → Search greps every request and response. Search for api, admin, token, or debug and you’ll find endpoints the UI never links to.
• Read the JavaScript. Single-page apps ship their whole route table to the browser. Searching the main bundle for /api/ often maps the backend in minutes.
• Check the boring files. robots.txt, sitemap.xml, and /.well-known/security.txt are public and routinely list paths or contacts you’d never guess.
• Use Comparer. When two responses look the same, send both to Comparer to diff them byte by byte. Tiny differences in length or timing are how you find blind issues.

Next steps

Finish the PortSwigger Apprentice labs for access control, authentication, and SQL injection. Then read How to Approach Your First CTF and start applying these skills under time pressure.