Testing VulnBank Against the OWASP Top 10 2025

Introduction

Modern web applications present complex attack surfaces where architectural oversights and logic flaws often lead to critical compromise. Assessing these risks requires practical, hands-on validation.

This article documents a penetration test of VulnBank, a Dockerized target environment, evaluated against the updated OWASP Top 10 2025 framework. Using Burp Suite and targeted testing methodologies, we systematically identify and exploit real-world vulnerabilities across five core categories:

• A01: Broken Access Control — IDOR, JWT manipulation for vertical privilege escalation, and Broken Object Property Level Authorization (BOPLA).
• A02: Security Misconfiguration — Unauthenticated exposure of sensitive AI system prompts and metadata via public API documentation.
• A05: Injection — SQL Injection (SQLi) and Cross-Site Scripting (XSS).
• A06: Insecure Design — Transactional business logic flaws (negative/zero-value transfers) and unrestricted file uploads allowing arbitrary script execution.
• A07: Authentication Failures — Broken password recovery and reset mechanisms.

Below is the technical walkthrough, proof-of-concept analysis, and remediation strategy for each finding.

A01:2025 — Broken Access Control

Access control enforces policy such that users cannot act outside of their intended permissions. With VulnBank running locally via Docker, we assess these controls using two standard user accounts (user1 and user2) with Burp Suite as Proxy.

(i). Insecure Direct Object References (IDOR)

Horizontal privilege escalation occurs when a user can access or modify resources belonging to another user of the same privilege level by manipulating object identifiers.

Steps to Reproduce

a. Log into VulnBank as user1 and do some transactions like Money transfer or Bill payment.

b. Log out of user1 account and log back into user2 account and navigate the transactions history.

c. Send the request with the transactions history to Burp Suite Repeater. Modify the account number in the URL path from 1841225782 (belonging to user2) to 7503952900 (belonging to user1).

The server responds with HTTP 200 OK, returning the account transaction history of user2 without verifying session ownership of the requested resource.

(ii). Vertical Privilege Escalation

Vertical privilege escalation allows a standard user to execute administrative actions or view restricted resources by bypassing server-side authorization checks.

Steps to Reproduce

a. Log in as a standard user1 and check the Burp Suite proxy for the request to the user dashboard.

Affected endpoint

GET /dashboard HTTP/1.1

GET /dashboard HTTP/1.1

b. Copy the session cookie and paste it into jwt.io . The is_admin : false key-value pair implies that this session is for standard user.

c. Modify the is_admin parameter to is_admin : true, username to admin and user_id to 1. Then use the new cookie token to send another request in the Burp Suite Repeater. This returns the admin dashboard.

d. To access this admin dashboard on the browser, go to Inspect >> Storage >>Cookies >> current session >> paste the new token to Value field. Reload the page and it returns the admin dashboard on the browser.

(iii). BOPLA

The registration endpoint fails to restrict client-controlled object properties during account creation, blindly trusting user-supplied parameters to assign elevated privileges or modify initial balances.

Affected Functionality

POST /register

POST /register

Steps to Reproduce

1. Register a new user and intercept this request on Burp Suite. Note that the is_admin parameter is set to false for standard user account.

2. Forward the request to BurpSuite Repeater to register a new user with admin priviledges and with account balance of your choice.

3. Login with these credentials and navigate to the Admin Control Panel. This account has elevated privileges of a system administrator. The user can also create other admin accounts and approve loans.

Remediation

• Implement robust, server-side authorization checks that validate resource ownership for every direct object reference.
• Use cryptographic signatures with strong, securely managed secrets for tokens (JWTs) and never trust client-side claims without server validation.
• Enforce explicit allowlists for object properties during data binding to prevent mass assignment and BOPLA vulnerabilities.

A02:2025 — Security Misconfiguration

Security misconfigurations occur when applications, frameworks, or servers are implemented with insecure default settings, verbose error handling, or exposed management interfaces. With VulnBank running locally via Docker, we evaluate the environment for default credentials, unconstrained directory listings, missing headers, and sensitive debug disclosures.

(i). AI System Info Exposure

The API documentation endpoint exposing internal AI system details lacks authentication, allowing unauthenticated users to access sensitive configuration data, AI system prompts, and implementation metadata.

Affected endpoint

GET /api/ai/system-info

GET /api/ai/system-info

Steps to Reproduce

1. Browse to the VulnBank API documentation page and locate the endpoint for retrieving AI agent system information.

2. Send a GET request to this endpoint and see what it reveals in Burp Suite Repeater

3. Observe the server response returning sensitive system prompt configurations, internal API metadata, and architectural details without requiring valid credentials.

Remediation

• Establish a repeatable, automated environment hardening process that removes default credentials, sample applications, and debug frameworks before deployment.
• Enforce strict authentication on all internal documentation and diagnostic endpoints, ensuring sensitive metadata is never publicly exposed

A05:2025 — Injection

Injection flaws occur when untrusted user input is sent to an interpreter as part of a command or query. With our local Docker instance of vulnbank.org running, we evaluate the application for injection vectors using Burp Suite across SQL and Cross-Site Scripting channels.

(i). SQL Injection (SQLi)

SQL injection occurs when untrusted user input is dynamically concatenated or passed directly into database queries without proper parameterization. This allows the attackers to manipulate query logic.

Steps to Reproduce

1. Attempt to log into the application via the browser interface using standard credentials.

2. Send the request to Burp Suite Repeater and try adding SQL scripts to the username field. The injections that worked include admin'--, admin' OR 1=1--, and admin' AND 1=1--

3. This injection worked even for other users whom we had created before. So long as we input the correct username, we could login without knowing their password through these SQL injections.

(ii). Cross-Site Scripting (XSS)

Stored Cross-Site Scripting occurs when user-supplied input is stored by the back-end and subsequently rendered back to users without proper output encoding, executing arbitrary client-side JavaScript.

affected endpoint

POST /transfer HTTP/1.1
Host: localhost:5000

POST /transfer HTTP/1.1
Host: localhost:5000

Steps to Reproduce

1. Proceed to make a money transfer to another user and in the payment description, insert the malicious payload script below:

<img src=x onerror=alert('owned')>

<img src=x onerror=alert('owned')>

The application fails to encode output correctly, demonstrating a lack of context-aware defensive output handling.

Remediation

• Utilize parameterized queries, prepared statements, or Object-Relational Mapping (ORM) frameworks for all database interactions to strictly separate user data from query execution logic.
• Implement context-aware output encoding (such as HTML entity encoding) before rendering any user-supplied data back to the browser.

A06:2025 — Insecure Design

Insecure design encompasses risks related to architectural and design flaws, focusing on design choices that cannot be fixed by secure coding alone. With our local Docker instance of vulnbank.org running, we evaluate the application for flawed business logic workflows and unrestricted file uploads.

i. Business Logic Flaws in Transactional Workflows

Business logic flaws stem from flawed application design assumptions regarding user behavior, allowing users to manipulate sequence workflows or execute unauthorized financial transactions.

The application allows for negative monetary transfers in which the amount to be transferred is deducted from the balance of the recipient regardless of whether the recipient has sufficient amount and provided that the sender has a balance greater or equivalent to the absolute of the amount to be transferred.

Steps to Reproduce

1. Log in to the account as user1 and notice the account balance.

2. Navigate to money transfer tab and make a negative amount transfer to admin account. Also make out a zero value transfer to the same account.

The backend business logic accepts out-of-order or mathematically invalid workflow states because authorization and verification rules were never structurally integrated into the application design.

Affected endpoint

POST /transfer HTTP/1.1
Host: localhost:5000

POST /transfer HTTP/1.1
Host: localhost:5000

ii. Unrestricted file upload and inadequate file-type validation

The profile picture upload functionality fails to validate uploaded files, accepting arbitrary types ranging from media files to executable scripts and storing them in a web-accessible directory.

affected endpoint

POST /upload_profile_picture HTTP/1.1

POST /upload_profile_picture HTTP/1.1

Steps to Reproduce

1. Navigate to the profile section and click Upload Photo.

2. Select a non-image file (such as a Python script, bash script, or PHP shell) and submit the upload.

3. Observe that the application accepts and stores the arbitrary file under /static/uploads/<id>_<original> within a web-accessible directory

Remediation

• Build strict business logic validation and numerical boundaries directly into server-side controllers.
• Enforce strict server-side file allowlists, magic-byte content validation, and secure storage configurations (such as storing uploads outside the web root or disabling execution permissions).

A07:2025 — Authentication Failures

Authentication flaws allow attackers to compromise passwords, keys, or session tokens. With our local Docker instance of vulnbank.org operational, we evaluate the application for authentication failures, focusing specifically on weak password recovery and reset mechanisms using Burp Suite.

i. Weak Password Recovery and Reset Mechanisms

A critical flaw was identified in the password reset functionality. The application exposes deprecated API versions for the same reset process, allowing an attacker to downgrade the workflow to a weaker implementation and retrieve a valid reset PIN directly from the server response.

Steps to Reproduce

1. Log out of standard user account and try resetting password for the admin account. The OTP is sent to the email which we did not set up during sign up.

2. By inspecting this forgot-password request we can notice that the API endpoint uses V3 which requires a 4-digit Reset PIN. Intercept this request and send it to Burp Suite Repeater. Change the API to version 1 and we can see a 3 digit OTP in the response

3. Get back to the New password reset and input the username, any 4 digit pin and new password. We notice the response shows an invalid reset pin.

4. Downgrade the API to version 1 and enter the 3 digit OTP initially and the new password. The password is reset successfully and we can log in as admin.

Remediation:

• Enforce strict API version control and remove deprecated, insecure API endpoints entirely from production environments to prevent version-downgrade attacks.
• Never return password reset tokens, OTPs, or temporary PINs in server responses. Generate cryptographically secure, time-bound tokens and deliver them exclusively through trusted, out-of-band communication channels.

Conclusion

Securing modern web applications requires moving beyond basic perimeter defenses to address foundational architectural and logic flaws. As demonstrated across VulnBank, vulnerabilities like JWT privilege escalation, unauthenticated API endpoints, business logic oversights, and insecure file uploads can completely compromise an environment regardless of infrastructure hygiene.

For system administrators and defenders, hardening production workloads demands a structured approach:

• Enforce Zero-Trust Access: Mandate server-side validation for all resource ownership and privilege boundaries.
• Eliminate Legacy Surfaces: Purge deprecated API versions, debug interfaces, and default credentials before deployment.
• Harden Data & Input Controls: Implement parameterized queries, strict file-type allowlists with magic-byte checks, and robust numerical boundary checks for transactional workflows.
• Secure Sensitive Mechanisms: Ensure recovery tokens and temporary credentials are never leaked in server responses.

Resilience is achieved by pairing secure coding standards with rigorous, continuous adversarial validation.