Why Burp Suite belongs in your dev toolkit
Security stopped being a theoretical “checkbox” for me at 3:00 AM on a Tuesday. I watched my server logs fill with over 10,000 failed SSH login attempts from a single botnet. That wake-up call changed my workflow forever. Now, I never assume code is safe just because it passes a unit test. I use Burp Suite to poke holes in my own logic before someone else does it for me.
Burp Suite Community Edition is the gold standard for intercepting proxies. Think of it as a transparent wall between your browser and the server. It lets you pause, read, and even rewrite web traffic in mid-air. While the Professional version costs $449 a year for automated scanning, the free Community version is incredibly powerful for manual audits if you know which levers to pull.
Getting Burp Suite ready in 5 minutes
Setting up an intercepting environment is where most people get stuck. Usually, it’s a certificate issue. Follow these steps to get it right the first time.
1. Configure the Proxy
Open Burp and head to the Proxy tab, then Proxy Settings. Ensure your listener is active on 127.0.0.1:8080. Don’t bother changing your entire system’s proxy settings; it’s a headache. Instead, install the FoxyProxy Standard extension on Firefox. Create a new profile for Burp on port 8080. This lets you toggle interception on and off with two clicks.
2. Install the CA Certificate
Almost every site today uses HTTPS. Without Burp’s root certificate, your browser will throw a massive security warning and block the connection. Turn your proxy on and visit http://burp. Click CA Certificate to download the file. Next, go to your browser’s certificate manager and import it. Make sure to check the box: “Trust this CA to identify websites.”
3. Catch your first request
Switch to the Proxy -> Intercept tab and make sure Intercept is on. Refresh any website. The request will freeze in time, appearing inside Burp. You can now hit Forward to let it through or Drop to delete it before it ever reaches the server.
Hands-on testing for common bugs
We’ll focus on three high-impact vulnerabilities. These are perfect for Burp’s Repeater tool. Repeater lets you take a single request and resend it dozens of times with different payloads without touching your browser.
1. Reflected Cross-Site Scripting (XSS)
XSS happens when an app echoes user input back to the screen without cleaning it first. Look for search bars, URL parameters like ?query=, or custom error messages.
- Find a search field and enter a unique string like
FIND_ME_123. - In Burp’s HTTP History, locate that
GETrequest. - Press
Ctrl+Rto send it to Repeater. - In Repeater, replace
FIND_ME_123with<script>alert('XSS')</script>. - Hit Send. If the response pane shows the script tag exactly as you typed it, you’ve found a vulnerability. If it shows
<script>, the developer has successfully sanitized the input.
2. SQL Injection (SQLi)
SQL Injection remains a top threat to databases. I always look for parameters that look like database keys, such as product_id=101 or cat=5. Even modern frameworks can be vulnerable if a developer uses raw queries for a “quick fix.”
To test for basic SQLi, send a request to Repeater and add a single quote (') to the value:
GET /api/products?id=101' HTTP/1.1
Host: example.comA 500 Internal Server Error or a message mentioning “MySQL” or “PostgreSQL” is a massive red flag. It means your quote broke the database query. To confirm, try a logic test. If id=101 AND 1=1 loads the page normally, but id=101 AND 1=2 returns an error or an empty page, the database is executing your injected code.
3. Insecure Direct Object Reference (IDOR)
IDOR is a logic flaw that scanners often miss. It occurs when an app trusts the user to tell it which record to access. Imagine you are viewing your own invoice at /billing/view?id=5001.
- Intercept the request for your invoice.
- Send it to Repeater.
- Change the ID from
5001to5000or4999. - Click Send.
If the server returns someone else’s invoice data, you’ve hit a critical IDOR. I always check this on “Update Profile” or “Download PDF” buttons. Developers frequently forget to verify if the logged-in user actually owns the requested ID.
Bypassing “Secure” Forms
Client-side validation is for user experience, not security. If a JavaScript form prevents you from entering a negative number or a long string, Burp bypasses that entirely. Since Burp catches the traffic after the browser is done with it, those JS checks no longer exist.
I once tested a checkout page where a “Quantity” dropdown only went from 1 to 10. By intercepting the request and changing the quantity to -1, the total price became negative, effectively adding a credit to the account. Always validate data on the server, because the client-side is under the attacker’s control.
Fuzzing with Intruder
The Community Edition throttles the speed of the Intruder tool, but it’s still great for small jobs. If you need to check if 50 different common files like .env or config.php exist on a server, Intruder is your best friend. Set the filename as a payload position, load your list, and let it run while you grab a coffee.
Final Tips for Better Testing
- Set Your Scope: Use the Target -> Scope tab to include only your testing URL. Filter your HTTP History to “Show only in-scope items.” This prevents your history from being cluttered by background traffic from Gmail or YouTube tabs.
- Use the Decoder: Don’t paste sensitive data into random “Base64 Decoder” websites. Burp has a built-in Decoder tab that handles URL, Base64, Hex, and more safely.
- Stay Legal: Only test apps you own or those with a public Bug Bounty program. Use these tools to build more resilient software, not to cause damage.
- Speed up with Keys: Master
Ctrl+R(Repeater) andCtrl+I(Intruder). Moving between these tabs quickly will save you hours during a deep audit.
Seeing your data “on the wire” gives you a perspective that code reviews simply can’t match. By using Burp Suite, you’ll start to see the hidden plumbing of the web, making you a much more effective developer and security researcher.
