For this project, I used the intentionally vulnerable banking application created by urlCommando-X on GitHubhttps://github.com/Commando-X/vuln-bank and tested it inside a containerized Docker environment to simulate a realistic API penetration testing workflow.

I wanted to actually exploit them.

So I built a vulnerable banking lab environment using Docker and tested the application like a penetration tester would in a real engagement. Using Burp Suite, JWT analysis, and backend code review, I identified multiple critical API vulnerabilities that exposed sensitive banking functionality.

The project focused on:

• Broken Object Level Authorization (BOLA)
• Broken Authentication
• Broken Object Property Level Authorization (BOPLA)
• JWT session weaknesses
• API request manipulation

The Lab Setup

I deployed the Damn Vulnerable Bank application inside Docker and routed browser traffic through Burp Suite Community Edition.

My workflow included:

• Intercepting HTTP requests
• Replaying requests in Burp Repeate
• Modifying account IDs and JSON parameters
• Capturing and reusing JWT tokens
• Reviewing backend authentication logic in VS Code

This gave me a realistic API penetration testing environment similar to modern web applications.

Finding #1: Broken Object Level Authorization (BOLA)

I intercepted a banking transaction request and modified the account identifier before replaying it to the server.

The result:

• 200 OK
• Successful API response
• Access to account-specific transaction data

The backend failed to verify whether the account actually belonged to my authenticated session.

This vulnerability demonstrated how attackers can abuse insecure APIs to enumerate or access other users' financial data simply by changing object IDs.

Finding #2: Broken Authentication and JWT Replay

Next, I tested the application's logout and token validation process.

After capturing a JWT during login, I logged out and replayed authenticated requests using the old token.

The server still accepted the request.

That meant:

• Sessions were not properly invalidated
• Old JWTs remained active after logout
• Authentication controls could be bypassed

I also reviewed the backend authentication code in VS Code to analyze how token validation was implemented.

Finding #3: BOPLA Through JSON Manipulation

I intercepted a loan request API call and modified the JSON body directly in Burp Repeater.

{
  "amount": 50
}

became:

{
  "amount": 100
}

The server accepted the manipulated value without additional validation.

This demonstrated a Broken Object Property Level Authorization issue where sensitive fields could be modified directly by the client.

Skills Demonstrated

This project helped me strengthen practical offensive security skills including:

• API penetration testing
• Burp Suite request manipulation
• JWT analysis
• Authorization testing
• Backend code review
• HTTP traffic interception
• Vulnerability validation
• Secure authentication analysis

Final Thoughts

One of the biggest things I learned from this project is how dangerous authorization flaws can be in API-driven applications.

Actually intercepting requests, replaying tokens, manipulating JSON data, and validating vulnerabilities gave me far more hands-on understanding than simply studying concepts.

Projects like this are helping me build practical experience in:

• Web application security
• API exploitation
• Penetration testing methodology
• Authentication security
• Offensive security workflows

And honestly, there's something satisfying about watching a manipulated request come back with 200 OK when it definitely shouldn't.

Tools used: Docker, Burp Suite Community Edition, VS Code, JWT analysis, API request manipulation.