Testing a banking app against the OWASP API top 10
As part of a 12-week API security course through APISEC University, I assessed Damn Vulnerable Bank, an app built to be broken into safely. The goal was to look at its API security using the OWASP API top 10 and find the weak spots in authentication, authorization, input handling, and configuration.
Understanding the system
Before testing for anything, I spent time understanding how the app worked. I mapped the user workflows, captured the API traffic, and found the endpoints handling accounts, authentication, and transactions. This gave me a baseline for how the app was meant to behave and where security controls should sit.
Authorization assessment
One of the first things I looked at was access control. After finding the account-related endpoints, I tested whether the app actually checked ownership when a user asked for data. By changing the object identifier in a request, I was able to reach resources belonging to other users. The app confirmed I was logged in, but it did not consistently check whether I was allowed to see what I was asking for. This is a Broken Object Level Authorization issue, one of the most common and serious problems in APIs.
Input validation assessment
I also looked at how the app handled user input. I found a spot that did not properly limit file path input, and by changing the request parameters I could move outside the intended directory and reach files that should not have been exposed. It was a clear example of how a small validation gap can lead to access it was never meant to allow.
Security configuration review
Beyond the application logic, I reviewed the configuration. One area was Cross-Origin Resource Sharing. I found settings that were more open than they needed to be, and while CORS is easy to overlook, a loose policy widens the attack surface and can expose sensitive functionality to origins that should not have it.
Communicating the findings
For each issue I wrote down the affected functionality, the steps to reproduce it, the potential impact, and how to fix it, and I prioritized them by what they would mean in a real banking environment. The final deliverable brought together the technical evidence, the risk, and practical remediation.