Burp Suite Tutorial: Find Web Vulnerabilities Step by Step

TL;DR

Burp Suite is the most widely used web application security testing tool, relied upon by over 70,000 organizations worldwide. This guide walks beginners through the entire workflow: installing Burp Community Edition, configuring your browser proxy, intercepting and modifying HTTP requests, crawling a web app, and using Repeater and Intruder to find SQL injection and cross site scripting vulnerabilities in DVWA. No prior pentesting experience required.

The login page looked normal. A simple form with two fields, a submit button, nothing unusual. But when Carla, a junior penetration tester on her first client engagement, typed a single apostrophe into the username field and clicked submit, the application responded with a full database error message. Table names, column references, the SQL query itself, all dumped onto the screen in plain text. She had found a SQL injection vulnerability in under thirty seconds, not because she was a genius, but because she knew how to use Burp Suite.

That discovery changed the entire engagement. The SQL injection led to full database extraction, which revealed stored passwords in plain text, which gave her access to the admin panel. One apostrophe. One tool. A complete compromise documented in her report by lunch.

Burp Suite is the tool that made it possible. Not by automating everything, but by giving Carla full visibility into every HTTP request and response flowing between the browser and the application. She could see what the application was doing, modify what it received, and test how it responded. That visibility is what separates someone who clicks buttons from someone who finds vulnerabilities.

What Is Burp Suite and Why It Matters

Burp Suite, built by PortSwigger, is an integrated platform for web application security testing. It works as a proxy that sits between your browser and the target web application, capturing every request and response for inspection and manipulation. Think of it as a security microscope for HTTP traffic.

The tool matters because web applications are the primary attack surface for most organizations. According to OWASP, injection flaws including SQL injection and cross site scripting have ranked among the top 10 web application security risks every year since the list was first published in 2003. The average cost of a data breach caused by a web application vulnerability reached 4.88 million USD in 2024 according to IBM's annual report. Finding these vulnerabilities before attackers do is not optional. It is the core job of web application pentesters.

Burp Suite Community Edition is free and includes everything you need to get started: the Proxy for intercepting traffic, Repeater for manually resending modified requests, Intruder for automated payload delivery (rate limited in the free version), Decoder for encoding and decoding data, and Comparer for spotting differences between responses. Over 60% of penetration testing job postings list Burp Suite as a required or preferred skill. Learning it is not just educational. It is a career investment.

Installing Burp Suite Community Edition

Burp Suite runs on Windows, macOS, and Linux. It requires Java, but the installer bundles its own Java runtime so you do not need to install anything separately.

Download the Community Edition from PortSwigger's official download page. Choose the installer for your operating system. On Linux, the download is a shell script:

chmod +x burpsuite_community_linux_v2024_x_x.sh
./burpsuite_community_linux_v2024_x_x.sh

On macOS, open the .dmg file and drag Burp Suite to your Applications folder. On Windows, run the .exe installer and follow the prompts.

Launch Burp Suite and select "Temporary Project" (the only option in Community Edition). On the next screen, select "Use Burp defaults" and click "Start Burp." The main interface loads with tabs across the top: Dashboard, Target, Proxy, Intruder, Repeater, and more. The Proxy tab is where you will spend most of your time as a beginner.

Configuring the Browser Proxy

Burp Suite works by intercepting HTTP traffic between your browser and the target application. To make this happen, you need to configure your browser to route traffic through Burp's proxy listener.

By default, Burp listens on 127.0.0.1:8080. You can verify this in the Proxy tab under "Proxy settings." The listener should show as running.

The easiest approach is to use Burp's built in Chromium browser. Click "Open browser" in the Proxy tab, and Burp launches a preconfigured browser that already routes traffic through the proxy. This avoids any system proxy configuration and keeps your testing isolated from your regular browsing.

If you prefer to use Firefox, install the FoxyProxy extension. Create a new proxy entry with the following settings:

• Proxy Type: HTTP
• Proxy IP: 127.0.0.1
• Port: 8080

Enable the proxy in FoxyProxy, then navigate to http://burpsuite in Firefox. This loads the Burp CA certificate download page. Download the certificate, then import it into Firefox through Settings, Privacy and Security, View Certificates, Import. This step is essential. Without the CA certificate installed, HTTPS connections will show security warnings because Burp performs a man in the middle interception to decrypt TLS traffic for inspection.

Once configured, every HTTP and HTTPS request from your browser flows through Burp Suite. You will see traffic appearing in the Proxy tab's HTTP history immediately.

Intercepting and Modifying Requests

The Proxy tab is the heart of Burp Suite. It has two modes: intercept on and intercept off. When intercept is on, Burp pauses every request before it reaches the server, letting you inspect and modify it. When intercept is off, traffic flows through normally but is still logged in the HTTP history.

Start with intercept off. Navigate to your DVWA instance in the browser, log in, and browse around. Switch to the Proxy tab and click "HTTP history." You will see every request listed with its method, URL, status code, length, and MIME type. Click any request to see the full headers and body in the lower pane. Click the "Response" tab to see what the server sent back.

Now turn intercept on. Navigate to the DVWA SQL Injection page and type admin in the User ID field. Click Submit. Instead of the page loading, Burp captures the request and displays it in the Intercept tab. You can see the full GET or POST request, including parameters, cookies, and headers.

This is where testing begins. Modify the id parameter from admin to 1' OR '1'='1 and click "Forward." The modified request reaches the server, and the response appears in your browser. If the application is vulnerable, it returns data it should not, because you altered the query the application executed against its database.

GET /vulnerabilities/sqli/?id=1'+OR+'1'%3d'1&Submit=Submit HTTP/1.1
Host: localhost
Cookie: PHPSESSID=abc123; security=low

That single modified request demonstrates the core workflow of web application testing: intercept, analyze, modify, forward, observe. Every vulnerability you find with Burp follows this pattern.

Using the Spider and Crawler

Before testing individual pages, you need a map of the entire application. Burp's Target tab builds this map as you browse, showing every host, directory, and file the application references. But manual browsing misses pages. The crawler automates discovery.

In the Target tab, right click your target host and select "Crawl" (in Community Edition, this is available through the Dashboard tab under "New scan" with "Crawl" selected). The crawler follows every link, submits forms with test data, and maps the application's structure. It discovers pages, parameters, and endpoints you might never find manually.

Once the crawl completes, the Target site map shows the full application tree. Directories expand to show files. Each file shows which parameters it accepts. This map becomes your testing checklist: every parameter is a potential injection point, every form is a surface to probe.

Review the site map with an attacker's mindset. Look for pages that accept user input: search forms, login pages, comment fields, file upload endpoints, URL parameters. These are the locations where SQL injection, cross site scripting, and other injection attacks are most likely to succeed.

Repeater: Manual Request Testing

Repeater is the tool you will use most after Proxy. It lets you send a request to the server, see the response, modify the request, and send it again, as many times as you need. No browser interaction required. Just raw HTTP request and response, side by side.

To send a request to Repeater, right click it in the Proxy HTTP history and select "Send to Repeater." Switch to the Repeater tab. The request appears in the left pane. Click "Send" and the response appears in the right pane.

Here is how to test for SQL injection using Repeater with a DVWA target. Start with the captured request from the SQL Injection page:

GET /vulnerabilities/sqli/?id=1&Submit=Submit HTTP/1.1
Host: localhost
Cookie: PHPSESSID=abc123; security=low

Modify the id parameter to send a single apostrophe: id=1'. Click Send. If the response contains a database error message like "You have an error in your SQL syntax," the parameter is injectable. The application is concatenating your input directly into a SQL query without sanitization.

Now escalate. Change the parameter to id=1' UNION SELECT user, password FROM users--. Send. If the response includes usernames and password hashes from the database, you have confirmed a UNION based SQL injection that extracts data from arbitrary tables.

Repeater excels at this iterative testing. Each modification builds on the previous one. You start with a probe (the apostrophe), confirm the vulnerability (the error message), then escalate to full exploitation (the UNION query). Document each step. Your pentest report needs to show the exact requests and responses that demonstrate the vulnerability.

Intruder: Automated Payload Delivery

Intruder automates the process of sending many variations of a request, each with a different payload. It is essential for brute force testing, parameter fuzzing, and vulnerability scanning across multiple input points. In Community Edition, Intruder is rate limited but still functional for learning.

To use Intruder, right click a request in Proxy or Repeater and select "Send to Intruder." The Intruder tab has four sub tabs: Positions, Payloads, Settings, and Results.

In the Positions tab, Burp highlights parameters it thinks you want to fuzz. Clear all positions with the "Clear" button, then select the specific value you want to test and click "Add." For example, highlight the value of the id parameter. The attack type "Sniper" sends one payload at a time to the marked position, which is what you want for most tests.

Switch to the Payloads tab. Under "Payload settings," add your test strings. For XSS testing, add payloads like:

<script>alert(1)</script>
<img src=x onerror=alert(1)>
"><script>alert(1)</script>
<svg onload=alert(1)>
'"><img src=x onerror=alert(1)>

For SQL injection, add:

' OR '1'='1
' UNION SELECT NULL--
' AND 1=1--
' AND 1=2--
1; DROP TABLE users--

Click "Start attack." Intruder sends each payload and shows the responses in a results table. Sort by response length or status code to spot anomalies. A response significantly longer or shorter than others suggests the payload triggered different behavior, which often indicates a vulnerability.

For XSS detection, search the response bodies for your payload strings. If <script>alert(1)</script> appears unencoded in the HTML response, the application is vulnerable to reflected cross site scripting. The browser will execute that script when a victim visits the crafted URL.

Finding XSS and SQL Injection in DVWA

DVWA provides intentional vulnerabilities at four security levels: low, medium, high, and impossible. Start at low and work up. Each level adds input validation that you must bypass, teaching you how real applications attempt (and fail) to prevent attacks.

SQL Injection at Low Security

Navigate to the SQL Injection page. Set DVWA security to "low" in the DVWA Security settings page. Type 1 in the User ID field, submit, and capture the request in Burp. Send it to Repeater.

Test the id parameter with: 1' OR '1'='1. The response returns all users in the database instead of just user 1. The application's SQL query looks like SELECT * FROM users WHERE user_id = '1' OR '1'='1', and since '1'='1' is always true, every row is returned.

Escalate with a UNION attack: 1' UNION SELECT user, password FROM users--. The response now includes usernames and their MD5 password hashes. This is a complete database compromise through a single input field.

Reflected XSS at Low Security

Navigate to the XSS (Reflected) page. Enter <script>alert(1)</script> in the name field and submit. The page reflects your input without encoding, and the script executes. In a real application, an attacker would craft a URL containing this payload and send it to a victim. When the victim clicks the link, the script runs in their browser session, potentially stealing cookies, session tokens, or credentials.

In Repeater, test variations that bypass common filters:

<img src=x onerror=alert(document.cookie)>
<svg/onload=alert('XSS')>
<body onload=alert(1)>

Each successful payload demonstrates a different vector. The onerror handler fires when the browser fails to load the nonexistent image. The onload handler fires when the SVG element renders. Understanding why each works helps you find XSS in applications that filter <script> tags but miss event handlers.

Building Your Web Security Testing Workflow

With Proxy, Repeater, and Intruder mastered, you have a complete testing workflow. Start every engagement the same way:

1. Map the application. Browse manually with Proxy capturing traffic. Run the crawler. Review the Target site map to identify every input point, form, parameter, and API endpoint.

2. Identify injection points. Every parameter that accepts user input is a candidate. URL parameters, form fields, HTTP headers (especially cookies and referrer), and JSON request bodies all deserve testing.

3. Test manually with Repeater. Send probe payloads to each injection point. Look for error messages, unexpected behavior, or reflected input in responses. Repeater gives you the precision to understand exactly what the application does with your input.

4. Automate with Intruder. Once you identify a promising parameter, use Intruder to send a full payload list. Compare response lengths and status codes to identify which payloads triggered vulnerabilities.

5. Document everything. Save requests and responses for your report. Burp's built in logging captures the full HTTP exchange. Each finding needs the exact request that triggers the vulnerability and the response that proves it exists.

This workflow applies to every web application, from a simple login form to a complex API with hundreds of endpoints. The tools scale with the target. Your job is to be methodical, covering every surface before concluding your test.

Beyond the Basics: PortSwigger Web Security Academy

Once you are comfortable with Proxy, Repeater, and Intruder in DVWA, move to PortSwigger's Web Security Academy. It is free, created by the same team that builds Burp Suite, and contains over 200 hands on labs covering every major web vulnerability class. Each lab runs in an isolated environment and walks you through the exact attack technique, from basic SQL injection to advanced server side request forgery and deserialization attacks.

The Academy structures learning by vulnerability type. Start with the SQL injection labs, then move to XSS, then authentication bypass, then access control. Each section builds on concepts from the previous one. By the time you finish the apprentice level labs, you will have practical skills that directly transfer to real engagements.

Pair the Academy with OWASP's Testing Guide, which documents the methodology professional pentesters follow. The Testing Guide explains what to test and why. The Academy teaches you how to test it using Burp Suite. Together, they build both the knowledge and the muscle memory that separate beginners from effective testers.

What to Practice Next

The path from beginner to competent web application tester follows a predictable progression. After DVWA, set up additional vulnerable applications: WebGoat for Java based vulnerabilities, Juice Shop for a modern single page application, and HackTheBox or TryHackMe for realistic scenarios. Each target teaches different vulnerability patterns and forces you to adapt your techniques.

Learn the Decoder tool for encoding and decoding Base64, URL encoding, HTML entities, and hex. Many payloads need encoding to bypass web application firewalls and input filters. Learn Comparer for spotting subtle differences between responses that indicate conditional behavior, which is the basis of blind SQL injection and timing attacks.

Consider extending Burp with community extensions from the BApp Store (Extensions tab). The "Logger++" extension adds enhanced logging. "Autorize" tests for access control vulnerabilities automatically. "Param Miner" discovers hidden parameters. Extensions multiply your effectiveness without requiring you to build custom tools from scratch.

Carla, the pentester who found SQL injection in thirty seconds, did not get lucky. She followed the same workflow you just learned: configure the proxy, intercept traffic, test parameters systematically, and use Repeater to confirm and escalate. The apostrophe was deliberate. The tool was ready. The only variable was the application's vulnerability. When you follow this process, finding your first real vulnerability is not a question of if. It is a question of when.