VULNBANK API SECURITY ASSESSMENT

Testing a Banking API Against the OWASP API Security Top 10

APIs are the backbone of modern applications, particularly financial applications where sensitive operations such as authentication, transactions, account management, and payments are exposed through API endpoints.

For this assessment, I performed hands-on security testing against VulnBank, a deliberately vulnerable banking application, using Burp Suite and the application's API documentation.

The assessment focused on the OWASP API Security Top 10 (2023).

Rather than attempting to force a vulnerability into every OWASP category, I documented only issues for which I could reproduce and retain evidence.

Testing Approach

The assessment involved:

Reviewing the API documentation
Creating multiple test accounts
Capturing legitimate API requests
Replaying and modifying requests using Burp Repeater
Testing authentication and authorization boundaries
Manipulating object identifiers
Reviewing API responses for excessive information exposure
Testing server-side URL fetching
Using Burp Intruder to assess login rate limiting

Confirmed / Observed Findings

API1: Broken Object Level Authorization: Confirmed

API3: Broken Object Property Level Authorization / Excessive Data Exposure: Confirmed

API4: Missing Rate Limiting: Observed

API7: Server-Side Request Forgery: Confirmed

No confirmed finding was established for API2 or API5.

This series breaks down each finding, the methodology used to test it, the evidence obtained, the security impact, and the appropriate remediation.

PART 1 — FINDING BOLA IN VULNBANK

Breaking Object-Level Authorization

One of the first things I wanted to test in a banking API was whether authorization was actually enforced at the object level.

This is where Broken Object Level Authorization (BOLA) becomes critical.

BOLA occurs when an API authenticates a user successfully but fails to verify whether that user is authorized to access the specific object being requested.

In a banking application, those objects could represent:

Accounts
Transactions
Cards
Payments
Financial records

For this test, I created two separate VulnBank users:

User A — Attacker

User B — Victim

The question was simple:

Can User A access User B's transaction data by changing an object identifier while keeping User A's authentication token?

Target Endpoint

GET /transactions/{account_number}

GET /transactions/{account_number}

The endpoint accepts an account_number identifying the account whose transactions should be returned.

Step 1 — Capture a Legitimate Request

I first captured a legitimate request using User A's authenticated session.

GET /transactions/{User-A-account-number}

GET /transactions/{User-A-account-number}

The request was then sent to Burp Repeater so I could manipulate individual parameters while keeping the rest of the request unchanged.

Step 2 — Change the Object Identifier

I changed only the account_number to User B's account number.

The authentication token remained associated with User A.

Conceptually:

User A token
     +
User B account_number
     ↓
GET /transactions/{User-B-account-number}

User A token
     +
User B account_number
     ↓
GET /transactions/{User-B-account-number}

The API returned:

HTTP/2 200 OK

HTTP/2 200 OK

and returned data associated with User B.

Why This Is BOLA

The server successfully authenticated the request as User A.

The problem was that authentication was apparently not followed by an object-level authorization check.

The critical relationship was:

Authenticated identity: User A
Requested object:       User B
Authorization result:   Allowed

Authenticated identity: User A
Requested object:       User B
Authorization result:   Allowed

The server should have determined whether User A was authorized to access the requested account before returning its transaction data.

Instead, changing the object identifier was sufficient to access another user's object.

That is a classic API1: Broken Object Level Authorization condition.

Impact

An authenticated attacker could potentially access another customer's financial information by modifying object identifiers.

Depending on the endpoint and the data returned, this type of authorization failure could expose:

Transaction history
Account information
Other financial records

If the same authorization weakness exists across multiple object endpoints, the impact could extend beyond a single resource.

Remediation

Object-level authorization must be enforced server-side for every request.

The API should verify that the authenticated user is authorized to access the requested object before returning it.

Do not rely solely on client-supplied identifiers such as:

account_number
user_id
transaction_id

account_number
user_id
transaction_id

The server must establish the relationship between the authenticated identity and the requested resource.

Conclusion

This test demonstrated a reproducible:

API1: Broken Object Level Authorization

The attack path was straightforward:

User A credentials
       ↓
Change object identifier
       ↓
User B's object
       ↓
200 OK
       ↓
Unauthorized data access

User A credentials
       ↓
Change object identifier
       ↓
User B's object
       ↓
200 OK
       ↓
Unauthorized data access

The important lesson is that authentication is not authorization.

A valid token only establishes who the requester is. The application still needs to determine whether that requester is allowed to access the specific object they requested.

Contents