Set Up a Hacking Lab and Find a Bug

Configure Burp Suite and exploit an IDOR vulnerability on a legal lab.

Introduction

30 Second Summary

Every app you use has security flaws. Companies like Google pay real money to people who find and report them responsibly. These people are called bug bounty hunters, and their core skill is knowing how to look at the traffic between a browser and a server.

In this project, you will set up a professional bug bounty testing lab and use it to find your first real vulnerability on a legal practice environment.

What You'll Build

A complete beginner's bug bounty hunting setup and workflow, from installing your interception proxy to writing a professional vulnerability report.

By the end of this project, you'll have:

  • A configured Burp Suite Community Edition intercepting proxy connected to Firefox via FoxyProxy.
  • A completed IDOR exploitation proving you accessed another user's private data on a legal practice lab.
  • A professional vulnerability report written in the format that gets accepted by programs like Google's VRP.
  • Secret Mission: Solve a harder IDOR lab using Burp Repeater to modify HTTP requests and steal another user's API key.

Are there any prerequisites?

You should have a basic understanding of HTML and be comfortable using the command line. You also need Firefox and a Java JDK already installed on your Windows machine.

No prior security experience is needed. This project teaches you everything from scratch.

Install and Configure Your Hacking Toolkit

Bug bounty hunting is about finding security vulnerabilities in web applications before attackers do. To find these bugs, you need a way to see and modify the traffic flowing between your browser and the websites you test.

In this step, you'll install Burp Suite Community Edition (an intercepting proxy), connect it to Firefox using FoxyProxy, and configure HTTPS interception so you can inspect encrypted traffic.

In this step, get ready to:
  • Install Burp Suite Community Edition and start a temporary project.
  • Configure FoxyProxy Standard to route Firefox traffic through Burp Suite.
  • Import Burp's CA certificate into Firefox for HTTPS interception.
Download and install Burp Suite Community Edition

Burp Suite is the industry-standard tool for web application security testing. The free Community Edition gives you everything you need for manual bug hunting.

  • Open Firefox.
  • Navigate to portswigger.net/burp/communitydownload.
  • Download the Windows (x64) installer. The site auto-detects your operating system.
  • Run the downloaded installer file.
  • When prompted to choose an edition, select Community Edition.
  • Follow the installation wizard and accept the defaults.

Why Community Edition?

Burp Suite Community Edition includes the full Proxy, HTTP History, and Repeater tools. These are all you need for manual vulnerability hunting. The paid Professional edition adds an automated scanner, but beginners focus on manual testing.

  • Launch Burp Suite by pressing the Windows key, typing Burp Suite, and pressing Enter.
  • On the startup wizard, select Temporary project and click Next.
  • On the configuration screen, leave Use Burp defaults selected and click Start Burp.

What is a temporary project?

A temporary project stores all your captured traffic in memory. When you close Burp Suite, the data is gone. This is perfect for learning since you do not need to save test data between sessions.

Burp Suite opens with the Dashboard tab visible. You should see several tabs along the top including Dashboard, Target, Proxy, and Repeater.

Burp Suite won't launch?

Burp Suite requires Java to run. Since you have the Java JDK installed, this should work automatically. If you see an error, make sure your Java installation is up to date.

help me troubleshoot why Burp Suite won't launch on Windows

Install FoxyProxy Standard in Firefox

FoxyProxy is a Firefox extension that lets you quickly switch your browser's proxy settings. You'll use it to route traffic through Burp Suite with a single click.

  • In Firefox, navigate to addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard/.
  • Click Add to Firefox.
  • When Firefox asks for permissions, click Add.
  • Click the FoxyProxy icon in the Firefox toolbar (top right area). If you don't see it, click the puzzle piece icon to find it under extensions.
  • Click Options to open the FoxyProxy settings page.

The FoxyProxy Options page opens in a new tab. This is where you configure proxy entries.

  • Add a new proxy entry with the following settings:
  • Set Title to Burp Suite.
  • Set Proxy Type to HTTP.
  • Set Hostname to 127.0.0.1.
  • Set Port to 8080.
  • Click Save.

What do these proxy settings mean?

The hostname 127.0.0.1 means "this computer" (localhost). Port 8080 is where Burp Suite listens for incoming traffic by default. Together, they tell Firefox to send all web traffic to Burp Suite running on your machine.

You should see your new Burp Suite proxy listed on the Options page. Do not activate it yet. You need to install the CA certificate first.

Don't see the FoxyProxy icon?

After installation, the icon might be hidden. Click the puzzle piece icon (Extensions) in the Firefox toolbar, find FoxyProxy Standard, and click the pin icon to keep it visible.

help me find the FoxyProxy icon in Firefox after installation

Install Burp's CA certificate in Firefox

Websites use HTTPS to encrypt traffic. Without a special certificate, Burp Suite cannot read encrypted requests. Installing Burp's CA certificate tells Firefox to trust Burp as a middleman, allowing it to decrypt and display HTTPS traffic.

  • Click the FoxyProxy icon in the Firefox toolbar.
  • Select the Burp Suite proxy to activate it. The FoxyProxy icon should change color to indicate it's active.
  • Navigate to http://burp in the Firefox address bar.
  • Click CA Certificate on the page that loads. This downloads a file called cacert.der.

What is http://burp?

This is a special address that only works when your traffic is flowing through Burp Suite. It serves Burp's internal pages, including the CA certificate download. If you see an error, make sure FoxyProxy is set to the Burp Suite proxy.

Now import the certificate into Firefox's trust store.

  • Open Firefox Settings (click the hamburger menu in the top right, then Settings).
  • In the search bar at the top of the Settings page, type Certificates.
  • Click View Certificates.
  • Go to the Authorities tab.
  • Click Import.
  • Select the cacert.der file you just downloaded (check your Downloads folder).
  • Check the box for Trust this CA to identify websites.
  • Click OK.

Why install a CA certificate?

HTTPS encrypts traffic so no one between you and the server can read it. Burp Suite sits between your browser and the server. Without this certificate, Firefox would show security warnings because it detects someone intercepting the connection.

By importing Burp's CA certificate, you tell Firefox that Burp is a trusted intermediary. This lets Burp decrypt, display, and re-encrypt HTTPS traffic without triggering errors.

Now verify that everything works end to end.

  • Make sure FoxyProxy is still set to the Burp Suite proxy (icon should be colored).
  • Navigate to https://www.google.com in Firefox.
  • The page should load normally with no certificate errors.
  • Switch to Burp Suite and click the Proxy tab.
  • Click HTTP history.
  • You should see requests to www.google.com listed in the history.

If you see the Google homepage and the requests appear in Burp's HTTP history, your hacking toolkit is fully configured.

Seeing certificate errors or a blank page?

If Firefox shows a security warning, the CA certificate was not imported correctly. Go back to Firefox Settings, search for Certificates, and verify that a PortSwigger entry appears under the Authorities tab. If not, repeat the import steps.

If the page does not load at all, confirm FoxyProxy is set to the Burp Suite proxy and that Burp Suite is still running.

help me fix certificate errors when using Burp Suite with Firefox

Your testing lab is ready. Next up, you'll use Burp Suite to intercept a live HTTP request and see exactly what your browser sends to a web server.

Intercept and Examine Your First HTTP Request

Your hacking toolkit is configured and ready. Burp Suite is running, FoxyProxy is routing Firefox's traffic through your proxy, and the CA certificate means HTTPS connections pass through without errors.

Now it is time to use your proxy for what it was built to do. Every time your browser talks to a website, it sends HTTP requests containing headers, cookies, and parameters. Bug hunters intercept these requests to understand how an application works before looking for weaknesses.

In this step, get ready to:
  • Intercept a live HTTP request and examine its structure.
  • Browse with intercept off and review all traffic in HTTP history.
  • Send a request to Burp Repeater, modify it, and resend it.
Intercept a live request with Burp Proxy

When interception is enabled, Burp Suite pauses every request your browser tries to send. The page freezes in Firefox because Burp is holding the request for you to inspect before it reaches the server.

  • Switch to Burp Suite and click the Proxy tab at the top of the window.
  • Click the Intercept sub-tab underneath.
  • Look at the toggle button. If it says Intercept is off, click it so it changes to Intercept is on.
  • Switch to Firefox (with FoxyProxy still set to Burp Suite) and navigate to any website, such as https://www.example.com.
  • The page will freeze and appear to hang. This is expected.
  • Switch back to Burp Suite. You will see the intercepted request displayed in the Proxy > Intercept panel.

Look at the intercepted request and identify the key parts: the request method (GET), the URL path, the Host header, and the Cookie header if present.

  • Click Forward to release the request and let it travel to the server.
  • Click Forward again for any subsequent requests that appear until the page loads in Firefox.

What just happened?

You paused a real HTTP request mid-flight. The browser sent the request, Burp caught it, you read its contents, and then you forwarded it to the server. This is the foundation of web security testing.

The Host header tells the server which website you are requesting. The Cookie header carries your session identity. Bug hunters look at these values to understand what data the browser sends automatically.

Page not freezing in Firefox?

Make sure FoxyProxy is set to the Burp Suite proxy (not Turn Off or another option). Also confirm the button in Burp says Intercept is on. If it says Intercept is off, click it to enable interception.

Help me troubleshoot why my browser is not being intercepted by Burp Suite. I have FoxyProxy configured to 127.0.0.1:8080 and Burp is running.

Browse with intercept off and explore HTTP history

Forwarding every single request manually gets tedious fast. Bug hunters typically leave intercept off and review all traffic afterwards in the HTTP history log.

  • In Burp Suite, click the Intercept is on button so it switches to Intercept is off.
  • Switch to Firefox and browse any website normally for 15 to 20 seconds. Click a few links so your browser generates multiple requests.
  • Switch back to Burp Suite and click Proxy then the HTTP history sub-tab.

You can now see every request your browser made listed in the table. Click on any request to see the full request details on the left and the server's response on the right.

What is HTTP history used for?

HTTP history is how bug hunters map an application's attack surface. Instead of intercepting one request at a time, you browse the application naturally and then review every interaction afterwards.

You can sort by host, method, URL, or status code to quickly find interesting requests. Requests to API endpoints, login pages, or pages with parameters are the most valuable for vulnerability hunting.

HTTP history is empty?

Confirm FoxyProxy is still set to the Burp Suite proxy in Firefox. If you accidentally turned it off, no traffic is flowing through Burp. Re-select the Burp Suite proxy in FoxyProxy and try browsing again.

My Burp Suite HTTP history is not showing any requests even though I am browsing in Firefox.

Send a request to Repeater and modify it

Burp Repeater lets you take any request from HTTP history, edit it, and resend it to see how the server responds differently. This modify-and-resend workflow is the core loop behind finding IDOR, XSS, and virtually every other web vulnerability.

  • In the HTTP history tab, find any request that looks interesting (a GET request to a real page works well).
  • Right-click on that request.
  • Select Send to Repeater from the context menu.
  • Click the Repeater tab at the top of Burp Suite.
  • You will see your request loaded in its own numbered tab, ready to edit.
  • Try making a small change to the request. For example, add a word to the end of the URL path.
  • Click Send to dispatch the modified request.
  • Observe the server's response on the right side. The response changes based on your modification.

Why is Repeater so important?

Repeater is where you spend most of your time as a bug hunter. Instead of reloading pages in the browser over and over, you edit a single request and click Send to test theories instantly.

Want to see if changing an ID number shows someone else's data? Change it in Repeater and send. Want to test if a header value causes an error? Swap it and send. This rapid experimentation is exactly how professionals find vulnerabilities.

Not seeing Send to Repeater in the menu?

Make sure you are right-clicking directly on a request row in the HTTP history table. The context menu appears with options including Send to Repeater. If you right-click elsewhere in the Burp window, you will see a different menu.

I cannot find the Send to Repeater option when I right-click in Burp Suite HTTP history.

You now have the core workflow that professional bug hunters use every day. Next, you will learn about Google's Bug Bounty Program so you know exactly where to hunt legally.

Understand Google's Bug Bounty Program and Scope

You have a working intercepting proxy that captures and replays HTTP traffic. Now it's time to learn where you're actually allowed to use these skills.

Bug bounty programs pay security researchers to find vulnerabilities in real products. Google runs one of the largest programs in the world through their Vulnerability Reward Program (VRP). Every program has strict rules about what you can test, how you can test it, and what counts as a valid finding.

In this step, get ready to:
  • Explore Google's Bug Hunters platform and understand the three-step reporting process.
  • Learn which targets are in scope and out of scope for Google's VRP.
  • Understand which vulnerability types qualify for rewards and what activities are prohibited.
Navigate to Google Bug Hunters

Google Bug Hunters is the central hub where security researchers report vulnerabilities, track submissions, and learn from educational resources. You don't need your proxy running for this step since you're just reading documentation.

  • In the FoxyProxy toolbar icon in Firefox, click Disable to turn off the Burp Suite proxy.
  • Navigate to bughunters.google.com in Firefox.
  • Read the landing page to see the three-step process Google outlines: Prepare (review the rules), Search (find vulnerabilities), and Report (submit for reward).
  • Optionally, create a free account on Google Bug Hunters to track your progress.

What is a bug bounty program?

A bug bounty program is an arrangement where companies invite security researchers to find and report vulnerabilities in their products. In return, researchers receive monetary rewards and public recognition.

Google's VRP covers products like Search, Gmail, YouTube, Google Cloud, and Chrome. It's one of the oldest and most established programs in the industry.

Review the VRP rules and scope

The rules page is the most important document for any bug bounty hunter. It defines exactly what you can and cannot test.

  • Navigate to the VRP Rules page by pasting this URL into your Firefox address bar:
bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules
  • Read the page and identify the three critical concepts below.

Here are the three concepts to look for:

  • In scope means Google-owned products and services that handle user data. These are the targets you are allowed to test.
  • Out of scope means third-party sites and customer-owned resources. Resources on *.appspot.com or *.bc.googleusercontent.com are strictly prohibited and make reports ineligible.
  • Qualifying vulnerability types include XSS, CSRF, authentication and authorization flaws, IDOR, and server-side code execution.

Why does scope matter so much?

Testing something outside the program's scope is unauthorized access. It can get your report rejected, your account banned, or even land you in legal trouble.

Always confirm a target is in scope before you start testing. When in doubt, don't test it.

Understand reward tiers and boundaries

Google's VRP rewards range from small credits to tens of thousands of dollars depending on severity and impact. Knowing the boundaries keeps you legal and helps you focus on what actually qualifies.

  • Note the key takeaway for beginners: IDOR, XSS, and access control bugs in Google-owned properties are valid targets you can start hunting for today.
  • Review the list of prohibited activities on the rules page.

Never do these things

Google's VRP explicitly prohibits the following activities:

  • Denial-of-service (DoS) attacks against any Google service.
  • Phishing attacks against Google employees.
  • High-volume automated scans or excessive automated traffic.
  • Testing customer-owned resources on *.appspot.com or *.bc.googleusercontent.com.

Violating these rules makes your report ineligible and may result in legal action. Always stay within the published boundaries.

What is IDOR and why start there?

An Insecure Direct Object Reference (IDOR) happens when an application lets you access another user's data just by changing a parameter like an ID number or filename. No special tools or scripting knowledge required.

IDOR is statistically the most common first bug found by beginners because the concept is simple: change a number, get someone else's data. You'll exploit one in the next step.

You now understand the rules of engagement for Google's bug bounty program. Next up, you'll put these skills to work by exploiting a real IDOR vulnerability on a legal practice lab.

Find Your First Vulnerability - IDOR on a Legal Lab

You now understand where to hunt legally and what kinds of bugs qualify for rewards. Time to put that knowledge into action by exploiting your first real vulnerability.

In this step, you will attack a live, intentionally vulnerable web application and exploit an IDOR (Insecure Direct Object Reference) vulnerability. This is the single most common bug type found by beginner bug hunters because it requires no special scripting. You simply change a value in a URL and gain access to someone else's private data.

In this step, get ready to:
  • Create a free PortSwigger Web Security Academy account and launch the IDOR lab.
  • Discover the IDOR vulnerability by observing how transcript filenames increment.
  • Exploit the vulnerability, steal a user's password, and solve the lab.
Create your Web Security Academy account and access the lab

PortSwigger's Web Security Academy is a free online training center with interactive labs purpose-built for each vulnerability type. You will use one of these labs as a safe, legal target for your first exploit.

  • In Firefox, navigate to portswigger.net/web-security.
  • Click Sign up and create a free account using your email.
  • Once signed in, navigate to the IDOR lab at portswigger.net/web-security/access-control/lab-insecure-direct-object-references.
  • Click Access the lab to launch a live, vulnerable application in your browser.

What is this lab?

This lab stores user chat logs directly on the server's file system and retrieves them using static URLs. Your goal is to find the password for the user carlos by manipulating a predictable file reference.

  • Click the FoxyProxy icon in your Firefox toolbar.
  • Select the Burp Suite proxy to re-enable it so all traffic flows through Burp.

The lab page should load normally with no certificate errors. You should see the lab's shop interface in your browser.

Lab page not loading?

Make sure Burp Suite is still running with your Temporary project. If you closed it earlier, relaunch Burp Suite and select Temporary project then Start Burp.

If you see a certificate error, your Burp CA certificate may not be installed correctly. Revisit the certificate installation steps from Step 1.

Help me fix my lab connection

Discover the IDOR vulnerability in the Live chat feature

The application has a chat feature that saves transcripts as downloadable files. Your job is to notice how those files are named and realize anyone can guess the pattern.

  • In the lab application, click the Live chat tab at the top of the page.
  • Type any message into the chat box (like hello) and send it.
  • Click View transcript to download a copy of your chat.
  • Look at the URL in your browser's address bar or check the filename of the downloaded file.

The transcript is a text file with an incrementing number in the filename (for example, 2.txt or 3.txt). This is the vulnerability. The filename is a direct object reference with no access control checking whether you are authorized to view it.

  • Switch to Burp Suite and go to Proxy then HTTP history.
  • Find the request that downloaded the transcript file (look for the .txt filename in the URL column).

Why is an incrementing filename dangerous?

If your transcript is 3.txt, it means transcripts 1.txt and 2.txt also exist on the server. Because the server does not check who is requesting the file, anyone can access any transcript just by guessing the number.

This is the classic IDOR pattern with static files. A secure application would use unpredictable identifiers (like UUIDs) and verify the requester's identity before serving the file.

Exploit the vulnerability and solve the lab

Now that you know the filenames are predictable and unprotected, you can access transcripts belonging to other users. Transcript 1.txt was created before your account existed, so it belongs to someone else.

  • Change the filename in the URL to 1.txt.
  • You can do this directly in the browser's address bar, or by sending the transcript request to Burp Repeater (right-click the request in HTTP history, select Send to Repeater) and modifying the filename there.
  • View the returned transcript. You should see a chat conversation belonging to another user that contains their password in plaintext.
  • Copy the password from the transcript.

What just happened?

You just performed a textbook IDOR exploitation. By changing a single number in a URL, you accessed another user's private data without any authentication check stopping you. This is exactly the kind of vulnerability that earns rewards on bug bounty programs like Google's VRP.

  • Return to the main lab page by clicking the lab's logo or navigating back.
  • Click My account at the top of the page.
  • Log in with the username carlos and the password you just stole from the transcript.

The lab displays a banner confirming you solved it. You just proved you can access another user's private data by exploiting a predictable file reference.

Lab not marking as solved?

Make sure you are logging in as carlos (not your own account). The password is inside the chat transcript in 1.txt.

If you downloaded the transcript instead of viewing it in the browser, open the downloaded .txt file in any text editor and look for the password line.

Help me troubleshoot the IDOR lab

You just exploited your first real vulnerability on a legal practice target. Next up, you will document this finding as a professional bug report in the format that gets accepted and paid on real programs.

Write a Professional Bug Report

You just proved you can find a real vulnerability. You accessed another user's private data by manipulating a predictable file reference.

Finding bugs is only half the job. The other half is communicating what you found clearly enough that a security team can reproduce it, assess the risk, and fix it. In this step, you will write a professional vulnerability report in the format that gets accepted by programs like Google's VRP.

In this step, get ready to:
  • Create a bug report file with a clear title, severity, and affected endpoint.
  • Write numbered reproduction steps that anyone can follow.
  • Document the impact and recommend a fix.
Create the report header

A strong report header tells the security team exactly what's wrong, how bad it is, and where to look. Programs that receive hundreds of submissions per week use this section to triage reports in under 30 seconds.

  • Press the Windows key to open your search bar.
  • Type VS Code and press Enter to open it.
  • Click File in the top menu bar.
  • Click New File.
  • When prompted to choose a language or file type, click Select a language, then choose Markdown.
  • Write the report header by pasting this into your new file:
# Bug Report

**Title:** IDOR in chat transcript download allows access to other users' chat history and credentials
**Severity:** High - exposes user credentials
**Affected Endpoint:** [[AFFECTED_ENDPOINT="transcript download URL from your lab, e.g. /download-transcript/1.txt"]]
**Date Found:** [[DATE_FOUND="today's date, e.g. 2026-06-27"]]

What does each field do?

  • Title names the vulnerability type (IDOR), the location (chat transcript download), and the impact (access to other users' data). This is what a triager reads first.
  • Severity tells the team how urgent this is. "High" is appropriate because the bug exposes plaintext passwords, enabling full account takeover.
  • Affected Endpoint points the team to the exact URL or path where the vulnerability lives.
  • Date Found establishes when you discovered the issue, which matters for disclosure timelines.

Find your affected endpoint

Look in Burp Suite's Proxy > HTTP history for the request that downloaded the transcript file. The URL path from that request is your affected endpoint.

Write the Steps to Reproduce section

The Steps to Reproduce section is the most important part of any bug report. If a security team cannot follow your steps and see the same result, your report will be marked invalid.

  • Add the Steps to Reproduce section below the header by pasting this into your file:
## Steps to Reproduce
1. Navigate to the Live chat feature.
2. Send a message and click 'View transcript'.
3. Observe the transcript URL contains an incrementing filename (e.g., 2.txt).
4. Modify the filename in the URL to 1.txt.
5. Observe another user's chat transcript is returned containing their password.

Why are these steps so specific?

Each step is a single, unambiguous action. Steps 3 and 5 include observations that describe what the tester should see at that point. This level of detail lets a triager reproduce the vulnerability in minutes without guessing.

Professional reports are rejected when they skip steps or use vague language like "exploit the IDOR." Specificity is what separates a paid report from an ignored one.

Write the Impact and Remediation sections

Impact explains why the bug matters in business terms. Remediation tells the engineering team how to fix it. Together, these sections demonstrate that you understand the full scope of what you found.

  • Add the Impact and Remediation sections below your Steps to Reproduce by pasting this:
## Impact
An attacker can enumerate transcript filenames and access any user's chat history without authentication. Chat transcripts contain sensitive information including plaintext passwords, enabling full account takeover.

## Remediation
Implement access controls on transcript downloads. Associate each transcript with the authenticated user's session and deny access to transcripts belonging to other users. Use non-sequential, unpredictable identifiers (UUIDs) instead of incrementing numbers.

What makes a strong Remediation section?

Your Remediation suggests three concrete fixes: add access controls, tie transcripts to sessions, and replace sequential IDs with UUIDs. Each fix addresses a different layer of the problem.

You do not need to write the actual code. Naming the right approach is enough. Security teams appreciate remediation suggestions because it saves them research time during triage.

  • Save the file by pressing Ctrl+S.
  • Name the file bug-report.md and save it to your Desktop.

Your file now has all five sections: Title, Severity, Affected Endpoint, Steps to Reproduce, and Impact with Remediation.

File didn't save as Markdown?

Make sure the filename ends with .md when you save. If VS Code saved it as a plain text file, rename it by right-clicking the file tab and selecting Rename.

Help me save my bug report as a Markdown file in VS Code.

✔️ Awesome, I've got everything!

Great. Double check you have saved bug-report.md and that it contains all five sections.

ⓧ I'd like to double check the full code

Here is the complete bug-report.md file for comparison:

# Bug Report

**Title:** IDOR in chat transcript download allows access to other users' chat history and credentials
**Severity:** High - exposes user credentials
**Affected Endpoint:** [[AFFECTED_ENDPOINT="transcript download URL from your lab, e.g. /download-transcript/1.txt"]]
**Date Found:** [[DATE_FOUND="today's date, e.g. 2026-06-27"]]

## Steps to Reproduce
1. Navigate to the Live chat feature.
2. Send a message and click 'View transcript'.
3. Observe the transcript URL contains an incrementing filename (e.g., 2.txt).
4. Modify the filename in the URL to 1.txt.
5. Observe another user's chat transcript is returned containing their password.

## Impact
An attacker can enumerate transcript filenames and access any user's chat history without authentication. Chat transcripts contain sensitive information including plaintext passwords, enabling full account takeover.

## Remediation
Implement access controls on transcript downloads. Associate each transcript with the authenticated user's session and deny access to transcripts belonging to other users. Use non-sequential, unpredictable identifiers (UUIDs) instead of incrementing numbers.

Secret mission

Exploit a Harder IDOR Using Burp Repeater

You solved your first IDOR by changing a filename in the URL bar. But real-world IDORs aren't always that simple. In this secret mission, you'll use Burp Repeater to modify an HTTP request parameter and steal another user's API key from a harder lab.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally with free online labs, so there are no ongoing costs.

Resources you used:

  • Burp Suite Community Edition (installed application on Windows).
  • FoxyProxy Standard extension (installed in Firefox).
  • Burp Suite CA certificate (imported into Firefox certificate store).
  • bug-report.md file (local file in VS Code).

Keep everything running

No action needed. Choose this if you plan to continue practicing on more PortSwigger labs or start hunting on live bug bounty programs.

  • Burp Suite stays installed and ready for your next testing session.
  • FoxyProxy stays configured so you can toggle your proxy on and off with one click.
  • The CA certificate remains trusted, allowing Burp to intercept HTTPS traffic without certificate errors.
  • Your PortSwigger Web Security Academy account tracks your solved labs and progress.

Pause - I'll come back to this later

Shut down running processes to free up memory. Keep everything installed so you can pick up where you left off.

  • Close Burp Suite completely.
  • In FoxyProxy, click the extension icon and select Turn Off (or Disable) so Firefox stops routing traffic through the proxy.
  • Your CA certificate, FoxyProxy configuration, and bug report file all remain in place for next time.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below to fully clean up.

  • Uninstall Burp Suite by opening Windows Settings, selecting Apps, then Apps & features. Find Burp Suite Community Edition in the list, click it, and select Uninstall.
  • Remove the Burp CA certificate from Firefox. Open Firefox Settings, search for Certificates, click View Certificates, go to the Authorities tab, find the PortSwigger entry, select it, and click Delete or Distrust.
  • Remove FoxyProxy Standard. In Firefox, click the menu button, select Add-ons and themes, find FoxyProxy Standard under Extensions, click the three-dot menu on it, and select Remove.
  • Delete your bug-report.md file. In VS Code, right-click the file in the Explorer sidebar and select Delete.

Nice Work!

Nice Work!

You just built a complete bug bounty hunting setup from scratch and used it to find real security vulnerabilities. You now have the exact same workflow that professional security researchers use to earn money hunting bugs on programs like Google's VRP.

Here's what you accomplished:

  • Configured a professional Burp Suite intercepting proxy connected to Firefox via FoxyProxy, giving you a complete web application testing lab.
  • Exploited a real IDOR vulnerability to access another user's private chat transcript and password on a legal practice lab.
  • Wrote a professional vulnerability report in the format that gets accepted and paid on real bug bounty programs.
  • Secret Mission: Used Burp Repeater to manipulate request parameters and steal another user's API key through a parameter-based IDOR.

Ready to quiz yourself?