Web Pentesting with Burp Suite

Exploit 5 real web vulnerabilities using Burp Suite and PortSwigger labs.

Introduction

30 Second Summary

Every time you log into a website or search for a product, your browser sends data to a server. Attackers know how to manipulate that data to bypass security, steal information, and take over accounts.

In this project, you will solve 5 real penetration testing labs using Burp Suite and document your findings in a professional pentest report. You'll exploit SQL Injection, Cross-Site Scripting, and Broken Access Control vulnerabilities on PortSwigger's Web Security Academy.

What You'll Build

A beginner-friendly penetration testing portfolio containing 5 completed PortSwigger Web Security Academy labs across 3 vulnerability categories, documented with screenshots and professional reporting.

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

  • 5 solved PortSwigger labs with evidence screenshots proving you can find and exploit real web vulnerabilities.
  • A professional Markdown pentest report documenting all findings with severity ratings, payloads, and remediation recommendations.
  • Portfolio deliverables including resume bullet points and a LinkedIn post template ready to publish.
  • Secret Mission: Solve a bonus authentication lab using Burp Intruder to brute-force a password after enumerating a valid username.

Are there any prerequisites?

None. This project includes full setup instructions for every tool you need. All you need is a Windows device with a web browser.

Before We Start

Penetration testers use specialized tools to find security flaws in web applications before attackers do. The industry-standard toolkit for this work is Burp Suite, which lets you intercept, inspect, and modify the traffic flowing between a browser and a web server.

In this step, you will install Burp Suite Community Edition, create a free PortSwigger Web Security Academy account, and get familiar with the key tools and concepts you will use throughout the project.

In this step, get ready to:
  • Install Burp Suite Community Edition on Windows.
  • Create a free PortSwigger Web Security Academy account.
  • Learn how Burp Suite's Proxy, Repeater, and Intruder tabs work and review key HTTP concepts.
Install Burp Suite Community Edition

Burp Suite is the tool you will use to intercept and manipulate web traffic in every lab. The installer is free and works on Windows, macOS, and Linux.

Which installer do I need?

Windows (x64) is correct for most Windows devices. To confirm, open Settings > System > About and check that System type shows "x64-based processor". If it shows "ARM-based processor", download the Windows (ARM) installer instead.

  • Once the download finishes, double-click the installer file to run it.
  • When prompted to choose an edition, select Community Edition.
  • Follow the installer prompts until Burp Suite launches.

What happens on first launch?

Burp Suite shows a startup wizard asking you to select a project file and configuration. You do not need to save a project for this guide.

  • Click Next on the project selection screen.
  • Click Start Burp on the configuration screen.

After a few seconds, the main Burp Suite dashboard appears with several tabs across the top.

Burp Suite not opening?

If the installer fails or nothing happens after double-clicking, make sure your Windows user account has admin privileges. Try right-clicking the installer and selecting Run as administrator.

If you see a Windows Defender SmartScreen warning, click More info and then Run anyway. The installer is safe.

help me troubleshoot my Burp Suite installation on Windows

Create a free PortSwigger Web Security Academy account

PortSwigger Web Security Academy hosts the vulnerable labs you will attack in this project. All Apprentice-level labs are completely free.

  • Open a new browser tab and go to:
  • https://portswigger.net/web-security
  • Click Sign up in the top right corner.
  • Fill in your email, choose a password, and submit the form.
  • Open your email inbox and click the verification link from PortSwigger.
  • Return to the Web Security Academy page and confirm you can see lab listings.

Not seeing the verification email?

Check your spam or junk folder. The email comes from PortSwigger and may take a minute to arrive.

help me with my PortSwigger account verification

Get oriented with Burp Suite and HTTP fundamentals

Before diving into the labs, take a moment to understand the three Burp Suite features you will use most. Each one gives you a different way to interact with web traffic.

  • Switch back to Burp Suite and look at the tabs across the top of the window.
  • Click the Proxy tab.
  • Inside the Proxy tab, click Open browser to launch Burp's built-in Chromium browser.

Why use Burp's built-in browser?

Burp's built-in browser is already configured to route all traffic through Burp's proxy. This means you do not need to manually configure proxy settings in your regular browser. Every request the built-in browser makes is automatically captured in Burp.

Here is what each key tab does:

  • Proxy tab: Intercepts HTTP requests between your browser and the target server. The HTTP history sub-tab shows every request that passed through.
  • Repeater tab: Lets you manually modify and resend individual HTTP requests. Perfect for testing attack payloads one at a time.
  • Intruder tab: Automates sending many requests with different payloads (like a list of passwords). Community Edition includes a rate-limited demo version.

What are HTTP requests, parameters, cookies, and status codes?

An HTTP request is a message your browser sends to a server. It contains a method (like GET or POST), a URL, headers, and sometimes a body.

Parameters are data sent along with the request. They appear in the URL (like ?category=Gifts) or inside the request body (like username=admin).

Cookies are small pieces of data the server stores in your browser to track your session. Status codes tell you the result: 200 means OK, 302 means redirect (often a successful login), 403 means forbidden.

Your tools are ready. Next up, you will use Burp Suite to exploit your first SQL Injection vulnerability in a live lab.

Complete the SQL Injection Labs

SQL Injection is one of the oldest and most dangerous web vulnerabilities. It works by tricking a database into running attacker-controlled commands through input fields that were only meant for normal data.

In this step, you will exploit two different SQL Injection flaws on live PortSwigger labs. The first lets you steal hidden data. The second lets you bypass a login page entirely.

In this step, get ready to:
  • Solve a SQL Injection lab that retrieves hidden product data.
  • Solve a SQL Injection lab that bypasses authentication to log in as administrator.
Lab 1: Retrieve hidden data with SQL Injection

This lab has a product category filter that passes your selection directly into a database query. The backend builds a query like this:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

What does this query do?

This query asks the database to return all products in the chosen category that have been officially released. The AND released = 1 part hides unreleased products from you. Your goal is to break past that filter.

  • In Burp Suite, go to Proxy > Open browser to launch Burp's built-in browser.
  • Navigate to the lab page: https://portswigger.net/web-security/sql-injection/lab-retrieve-hidden-data
  • Click Access the lab to launch a fresh instance of the vulnerable application.
  • Click on any product category (e.g., Gifts) and observe the URL changes to include a category parameter.
  • In Burp Suite, switch to the Proxy tab and click HTTP history.
  • Find the GET request with the category parameter in the URL.
  • Right-click the request and select Send to Repeater.

What is Repeater?

Burp Repeater lets you manually edit and resend individual HTTP requests. This is perfect for testing attack payloads because you can tweak the request and instantly see how the server responds.

  • Click the Repeater tab to see your captured request.
  • In the request, find the category parameter value (e.g., Gifts).
  • Replace the category value with this payload:
'+OR+1=1--
  • Click Send and observe the response. It now contains unreleased products that were previously hidden.
  • Switch back to Burp's browser and modify the URL directly. Replace the category value in the address bar with '+OR+1=1-- to solve the lab.

The lab banner should say "Congratulations, you solved the lab!"

What did I just do?

You injected SQL code into a URL parameter. Here is how the payload works:

  • The ' closes the original string that the application wrapped around your input.
  • OR 1=1 makes the WHERE clause always true, so the database returns all products including unreleased ones.
  • -- is a SQL comment. It tells the database to ignore everything after it, which removes the AND released = 1 restriction.
  • Capture your screenshot evidence for Lab 1. Take three screenshots:
  • The Repeater tab showing your modified request with the '+OR+1=1-- payload.
  • The response panel showing unreleased products.
  • The "Congratulations, you solved the lab!" banner in the browser.

Lab not showing as solved?

Sending the payload in Repeater alone does not solve the lab. You must also submit the payload in the browser's address bar so the lab page registers the solution.

If the lab has expired (each instance has a time limit), click Access the lab again to launch a fresh instance and retry.

Help me troubleshoot my SQL Injection lab. I modified the category parameter but the lab is not showing as solved.

Lab 2: Bypass authentication with SQL Injection

This lab has a login form where the backend checks credentials using a SQL query. If you can manipulate that query, you can log in without knowing the password.

administrator'--
  • In the Password field, type anything (e.g., test). The password does not matter for this attack.
  • Click Log in.

You are now logged in as administrator. The lab should be solved.

What did I just do?

The backend query looked something like:

SELECT * FROM users WHERE username = 'administrator'--' AND password = ''

By putting '-- after administrator, you closed the username string and commented out everything that followed. The database returned the administrator user without ever checking the password.

Verify Lab 2 in Repeater

You solved the lab in the browser, but let's also confirm the attack in Repeater. This helps you understand the raw HTTP request that made it work.

  • In Burp Suite, go to Proxy > HTTP history.
  • Find the POST /login request (the one you just submitted).
  • Right-click the request and select Send to Repeater.
  • In the Repeater tab, confirm you can see administrator'-- in the username parameter.
  • Click Send and observe the response shows a 302 status code. This means a redirect (login success).

Why is 302 a success signal?

A 302 response means the server is redirecting you to another page. After a successful login, servers typically redirect you to your account dashboard. A failed login would return a 200 with the login form again (plus an error message).

  • Capture your screenshot evidence for Lab 2. Take three screenshots:
  • The Repeater tab showing the POST /login request with administrator'-- in the username field.
  • The response showing the 302 status code.
  • The "Congratulations, you solved the lab!" banner in the browser.

Not seeing the 302 in Repeater?

Make sure you selected the correct request from HTTP history. Look for a POST request to /login, not a GET request. The login form submits data via POST.

If the lab expired, launch a fresh instance and repeat the login with administrator'-- as the username.

Help me find the correct request in Burp's HTTP history for the login bypass lab.

Two labs down and two critical vulnerabilities proven. Next up, you will exploit a completely different attack type: injecting JavaScript into a web page using Cross-Site Scripting.

Complete the XSS Lab

Your SQL injection labs proved that unsanitized database queries let attackers manipulate backend logic. Now you're shifting to the other side of the stack: the browser.

Cross-Site Scripting (XSS) targets the frontend. Instead of injecting SQL into a database query, you inject JavaScript into a web page. In this step, you'll exploit a search box that reflects your input straight into the HTML without any filtering.

In this step, get ready to:
  • Solve the Reflected XSS lab by injecting a JavaScript payload into a search box.
  • Use Burp Repeater to inspect the raw HTML response and confirm the script tag was not encoded.
  • Capture screenshot evidence of the alert popup, unencoded HTML, and solved banner.
Inject a script tag through the search box

This lab has a search box that reflects your input directly into the page HTML without any sanitization. Whatever you type in the search box appears word-for-word in the response.

Now that you've confirmed the application reflects your input without encoding, it's time to inject actual JavaScript.

  • Type the following payload into the search box: <script>alert(1)</script>.
  • Click Search.

A JavaScript alert popup should appear in the browser, and the lab banner should say "Congratulations, you solved the lab!"

What did I just do?

You injected JavaScript code through the search box. Because the application did not encode special characters (like < and >), your script tag was treated as real HTML and executed in the browser.

In a real attack, this could steal session cookies or redirect users to malicious sites. The fix is simple: encode all user input before rendering it in HTML.

No alert popup appeared?

Make sure you are using Burp's built-in browser, not your regular browser. Some modern browsers block inline script execution by default.

Double check that you typed the payload exactly as shown, including both the opening and closing script tags. A missing / in the closing tag will break it.

Why isn't my XSS payload triggering an alert in the browser?

Observe the attack in Burp Repeater

The alert popup proves the attack worked, but let's look under the hood. Burp Repeater lets you inspect the raw HTTP response to see exactly how the server returned your unencoded script tag.

  • In Burp Suite, click the Proxy tab, then click HTTP history.
  • Find the GET request that contains your XSS payload in the search parameter. Look for the request with <script>alert(1)</script> in the URL.
  • Right-click the request and select Send to Repeater.
  • Click the Repeater tab to switch to it.
  • Click Send to resend the request.
  • In the Response panel, look at the HTML body. You should see your <script>alert(1)</script> rendered directly in the page source without any encoding.

What should I see in the response?

The response HTML contains your script tag as literal HTML, not as encoded text. If the application were secure, it would have converted < to &lt; and > to &gt; so the browser treats them as text, not as HTML tags.

Capture your screenshot evidence

Take three screenshots to document this lab for your portfolio.

  • Screenshot 1: The alert(1) popup visible in Burp's browser.
  • Screenshot 2: The Repeater response panel showing your unencoded <script>alert(1)</script> in the HTML source.
  • Screenshot 3: The "Congratulations, you solved the lab!" banner.

Keep your screenshots organized

Save these screenshots in the same folder as your Lab 1 and Lab 2 evidence. Name them clearly (e.g., lab3-alert-popup.png, lab3-repeater-response.png) so you can reference them easily when writing your report.

Three labs down. You've now exploited vulnerabilities on both the backend (SQL injection) and the frontend (XSS). Next up, you'll target a completely different weakness: broken access control, where the server simply forgets to check who's allowed to see what.

Complete the Broken Access Control Lab

You have proven you can inject SQL and execute scripts in a victim's browser. Now you will tackle a different class of vulnerability: Broken Access Control.

Access control flaws occur when an application fails to restrict who can reach sensitive pages or features. In this lab, you will discover a hidden admin panel that anyone can access without logging in, and use it to delete a user account.

In this step, get ready to:
  • Solve the Unprotected Admin Functionality lab by discovering a hidden endpoint via robots.txt.
  • Capture screenshot evidence of the exploit.
  • Create a professional pentest report documenting all your findings so far.
Solve the Unprotected Admin Functionality lab

This lab has an admin panel that exists at a hidden URL. The developers assumed nobody would find it, but they accidentally revealed the path in a publicly readable file.

You should see a shop homepage with product listings, similar to the previous labs.

Check robots.txt for hidden paths

A robots.txt file tells search engine crawlers which pages they should not index. Attackers check this file because it often reveals paths the developer wanted to hide.

  • In the browser address bar, replace everything after the lab domain with /robots.txt and press Enter.
  • Read the file contents. Notice the Disallow line reveals the path /administrator-panel.

What is robots.txt?

The robots.txt file is meant for search engines, not security. It says "please don't index these paths" but it does not enforce any access restriction.

Attackers routinely read robots.txt because it reveals exactly which paths the developer considered sensitive. If those paths lack authentication, you can walk right in.

Access the admin panel and delete the target user
  • In the address bar, replace /robots.txt with /administrator-panel and press Enter.
  • You now see the admin panel with a list of users. No login was required.
  • Click the Delete link next to the user carlos.

The lab banner should now say "Congratulations, you solved the lab!"

What did I just do?

You found a hidden admin page by checking robots.txt. The developers thought hiding the URL was enough security, but "security through obscurity" is not real protection.

Any determined attacker can discover hidden endpoints through robots.txt, JavaScript source code, or directory brute-forcing. The fix is to enforce proper authentication and authorization checks on every sensitive endpoint.

Capture your screenshot evidence
  • Take a screenshot of the robots.txt page showing the Disallow: /administrator-panel line.
  • Take a screenshot of the admin panel showing the user list and delete interface.
  • Take a screenshot of the "Congratulations" banner confirming the lab is solved.

Check your Proxy history

Switch back to Burp Suite and open Proxy > HTTP history. You should see your requests to /robots.txt and /administrator-panel logged there.

Lab not showing as solved?

Make sure you deleted the user carlos specifically. The lab only completes when that exact user is removed.

If you see a 404 error when navigating to /administrator-panel, double-check that you are editing the lab URL (the long random subdomain), not the PortSwigger main site URL.

Help me troubleshoot my access control lab

Write your findings report

A pentest report is the professional deliverable that proves your work. You will now create a Markdown file documenting all four labs you have completed, plus a placeholder for the Secret Mission lab.

  • Open any text editor on your computer (Notepad, VS Code, or whichever you prefer).
  • Create a new file and save it as pentest-report.md on your Desktop.
  • Paste the following report template into the file:
# Web Application Penetration Testing Report

## Executive Summary
Conducted a penetration test against PortSwigger Web Security Academy lab applications. Identified and exploited 5 vulnerabilities across SQL Injection, Cross-Site Scripting, and Access Control categories.

## Methodology
- Tools: Burp Suite Community Edition 2026.4.3
- Target: PortSwigger Web Security Academy Labs
- Approach: Manual testing using Burp Proxy, Repeater, and Intruder

## Findings

### Finding 1: SQL Injection - Data Retrieval
- Severity: High
- Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data
- Location: Product category filter parameter
- Payload: '+OR+1=1--
- Impact: Attacker can retrieve all products including unreleased/hidden items
- Remediation: Use parameterized queries instead of string concatenation

### Finding 2: SQL Injection - Authentication Bypass
- Severity: Critical
- Lab: SQL injection vulnerability allowing login bypass
- Location: Login form username field
- Payload: administrator'--
- Impact: Attacker can bypass authentication and log in as any user
- Remediation: Use parameterized queries for authentication logic

### Finding 3: Reflected Cross-Site Scripting
- Severity: Medium
- Lab: Reflected XSS into HTML context with nothing encoded
- Location: Search functionality
- Payload: <script>alert(1)</script>
- Impact: Attacker can execute JavaScript in victim's browser (cookie theft, session hijacking)
- Remediation: Encode all user input before rendering in HTML (use HTML entities for < > " ' &)

### Finding 4: Broken Access Control - Unprotected Admin Panel
- Severity: Critical
- Lab: Unprotected admin functionality
- Location: /administrator-panel (discovered via robots.txt)
- Impact: Any user can access admin functionality and delete accounts
- Remediation: Implement proper authentication and authorization checks on admin endpoints

### Finding 5: Username Enumeration via Response Differences
- Severity: Medium
- Lab: Username enumeration via different responses
- Location: Login form
- Impact: Attacker can identify valid usernames by comparing error messages, then brute-force passwords
- Remediation: Use generic error messages ("Invalid username or password") for all login failures

## Conclusion
All 5 vulnerabilities were successfully exploited. The most critical findings are the SQL Injection authentication bypass and the unprotected admin panel, both of which grant full administrative access without valid credentials.

What does this report cover?

Each finding follows a standard pentest report format: severity rating, location, proof-of-concept payload, business impact, and a remediation recommendation. This structure is what hiring managers expect to see from security candidates.

Finding 5 is a placeholder for the Secret Mission lab. If you complete it later, the details are already outlined for you.

  • Save pentest-report.md.
  • Confirm the file exists on your Desktop by checking for pentest-report.md in File Explorer.

File saved as .txt instead of .md?

In Notepad, when you save, change the Save as type dropdown from "Text Documents (*.txt)" to "All Files (*.*)". Then type the full filename pentest-report.md including the extension.

Help me save my Markdown file correctly

Four labs down. Your report is taking shape. Next, you will turn all of this evidence into polished portfolio deliverables ready for hiring managers.

Build Your Portfolio Deliverables

Your pentest report documents four real vulnerabilities you identified and exploited across SQL Injection, XSS, and Broken Access Control. That's real evidence of hands-on security skills.

Hiring managers in cybersecurity want proof that you can find and exploit vulnerabilities, not just talk about them. In this step, you'll turn your lab results into resume bullet points, a LinkedIn post template, and an organized portfolio folder that's ready to share.

In this step, get ready to:
  • Draft resume bullet points from your pentest findings.
  • Create a LinkedIn post template to share your achievement.
  • Organize all deliverables into a portfolio folder.
Draft resume bullet points

The best cybersecurity resumes show specific tools, specific vulnerabilities, and specific outcomes. Generic statements like "familiar with penetration testing" mean nothing to a hiring manager who reviews hundreds of applications.

  • Copy the following bullet points and save them for the Projects or Experience section of your resume:
- Identified and exploited 5 web application vulnerabilities (SQL Injection, XSS, Broken Access Control) using Burp Suite against PortSwigger Web Security Academy labs
- Documented findings in a professional penetration testing report with severity ratings, proof-of-concept payloads, and remediation recommendations
- Demonstrated proficiency with Burp Suite Proxy, Repeater, and Intruder for manual web application security testing

Why do these bullet points work?

Each bullet names a specific number (5 vulnerabilities), specific tools (Burp Suite Proxy, Repeater, Intruder), and specific vulnerability types (SQL Injection, XSS, Broken Access Control). Recruiters scanning resumes look for these concrete signals.

The third bullet shows you can do more than click buttons. It proves you understand manual testing methodology, not just automated scanning.

Create your LinkedIn post template

A LinkedIn post about your pentesting work signals to recruiters that you're actively building skills. It also helps other beginners see what's possible.

  • Copy the following post template and customize it with your own voice before publishing:
I just completed my first 5 web penetration testing labs using Burp Suite!

Here's what I exploited:
- SQL Injection to bypass authentication
- SQL Injection to retrieve hidden data
- Reflected XSS to execute JavaScript
- Broken Access Control to access admin panels
- Username Enumeration to identify valid accounts

Key takeaways:
1. SQL comments (--) can completely bypass password checks
2. User input MUST be sanitized before rendering in HTML
3. "Security through obscurity" (hidden URLs) is not real security
4. Different error messages leak information to attackers

Tools used: Burp Suite Community Edition, PortSwigger Web Security Academy

All labs documented in a professional pentest report format.

Next up: More advanced labs and working toward my first security certification.

#cybersecurity #pentesting #burpsuite #websecurity #infosec

What makes this post effective?

The post opens with a concrete achievement (5 labs), lists specific vulnerability types to show breadth, and ends with hashtags that cybersecurity recruiters actually search for.

The "Key takeaways" section shows you understand the security concepts behind the attacks, not just how to follow steps. That's what separates a strong candidate from someone who just ran a tool.

Organize your portfolio folder

Having all your evidence in one place makes it easy to attach to job applications or pull up during interviews. You'll create a single folder with everything a hiring manager needs to see.

  • Create a new folder on your Desktop called pentesting-portfolio.
  • Move your pentest-report.md file into the pentesting-portfolio folder.
  • Move all your lab screenshots (from Labs 1 through 4) into the same folder.
  • Save your LinkedIn post template as a text file (e.g., linkedin-post.md) inside the pentesting-portfolio folder.
  • Open File Explorer and navigate to your Desktop.
  • Confirm that your pentesting-portfolio folder contains your pentest report, screenshots, and LinkedIn post template.

What should I see?

Your pentesting-portfolio folder should contain at minimum: pentest-report.md, your LinkedIn post file, and several screenshot images from Labs 1 through 4.

Export your report as a PDF

A PDF version of your pentest report looks more polished when attached to job applications. Here are two quick ways to create one:

  • If using VS Code: Install the "Markdown PDF" extension, open your .md file, press Ctrl+Shift+P, and select "Markdown PDF: Export (pdf)".
  • If using any browser: Paste your Markdown into https://markdownlivepreview.com/, then use File > Print > Save as PDF.

Folder missing files?

Make sure you moved (not just copied) your files into the pentesting-portfolio folder. If you cannot find your screenshots, check your Downloads folder or wherever your browser saves images by default.

Help me find my lab screenshots and organize my portfolio folder.

Your portfolio is ready to share. You've got documented proof of real security testing skills, formatted for the places hiring managers actually look. If you're ready for one more challenge, the Secret Mission introduces Burp Intruder for automated password brute-forcing.

Secret mission

Username Enumeration with Burp Intruder

Ready to try automated attacks? This bonus lab introduces Burp Intruder to brute-force a login form. You will enumerate a valid username by spotting subtle response differences, then crack the password with a second automated attack.

Clean Up Your Resources

Clean Up Your Resources

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

Resources you used:

  • Burp Suite Community Edition (installed on your Windows device).
  • The pentesting-portfolio folder containing your pentest report and lab screenshots.

Keep everything running

No action needed. Choose this if you plan to continue solving more PortSwigger labs or want to keep your portfolio materials handy.

  • Burp Suite stays installed and ready for future labs.
  • Your pentesting-portfolio folder stays on your device with your report and screenshots.
  • Your PortSwigger Web Security Academy account remains active for free. You can access additional Apprentice and Practitioner-level labs at any time.

Pause - I'll come back to this later

Shut down Burp Suite to free up memory. Your files and account stay intact for when you return.

  • Close Burp Suite by clicking the X button or selecting Burp then Exit from the menu bar.
  • Your pentesting-portfolio folder remains on your device. No need to move or back it up unless you want to.
  • Your PortSwigger account stays active. Solved labs remain marked as complete when you sign back in.

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 from your Windows device.
  • Open Settings.
  • Select Apps, then Installed apps.
  • Search for Burp Suite Community Edition.
  • Click the three-dot menu next to it and select Uninstall.
  • Delete your portfolio folder by opening PowerShell and running:
Remove-Item -Recurse -Force ~\Desktop\pentesting-portfolio

Folder in a different location?

If you saved your pentesting-portfolio folder somewhere other than your Desktop, replace ~\Desktop\pentesting-portfolio with the actual path to your folder.

  • Confirm the folder is gone by running:
ls ~\Desktop\pentesting-portfolio

You should see an error indicating the path does not exist. This confirms the folder has been deleted.

Nice Work!

Nice Work!

You just completed 5 real penetration testing labs and documented them like a professional. You now have a portfolio that proves you can find and exploit web vulnerabilities using industry-standard tools.

Here's what you accomplished:

  • Exploited SQL Injection, Cross-Site Scripting, and Broken Access Control vulnerabilities across 4 PortSwigger Web Security Academy labs using Burp Suite Proxy and Repeater.
  • Created a professional Markdown pentest report documenting 5 findings with severity ratings, proof-of-concept payloads, and remediation recommendations.
  • Built job-ready portfolio deliverables including resume bullet points, a LinkedIn post template, and an export-ready report folder.
  • Secret Mission: Solved a username enumeration lab using Burp Intruder to automate credential discovery through response analysis.

Ready to quiz yourself?