APIs are at the core of modern applications, especially in systems like banking where data needs to move quickly and securely between services. They make things efficient, scalable, and easy to integrate. But if security is not properly enforced, APIs can quickly become one of the weakest points in an application.

In this assessment, I tested the OpenVault Bank API, a deliberately vulnerable environment from APISec University, to understand how real-world API flaws can be discovered and chained together based on the OWASP Top 10 (2023). What started as a normal user session quickly escalated into full administrative control and unauthorized financial manipulation.

OWASP Vulnerabilities Exploited

1. API1:2023- Broken Object Level Authorization (BOLA)
2. API2:2023- Broken Authentication
3. API3:2023- Broken Object Property Level Authorization (BOPLA)
4. API5:2023- Broken Function Level Authorization (BFLA)

Attack Chain Analysis

Step 1: Creating a Normal User Account

I began the assessment by registering a new user account:

POST {{baseUrl}}/api/v1/auth/register

Using:

{
 "email": "user1@mail.com",
 "password": "******"
 }

The API successfully created the account and returned a JWT access token. This token immediately granted authenticated access as a standard customer.

Step 2: Creating a Second Test User

To validate how the system handles multiple accounts, I created a second user:

{
 "email": "user@mail.com",
 "password": "******"
 }

This also returned a valid access token. This token is what grants access to other endpoints, so at this point, I was operating strictly as a normal customer.

Step 3: Testing Access to Transaction Details

OWASP API1:2023 -Broken Object Level Authorization (BOLA)

Next, I wanted to see how well the API enforces ownership of resources. I started by viewing transactions tied to my account:

GET {{baseUrl}}/api/v1/accounts/:account_id/transactions

At this point, everything worked as expected. However, instead of stopping there, I changed the account_id from my own ID to another user's ID.

Surprisingly, the API still returned valid transaction data of the other users.

I repeated this with multiple IDs (2002, 2003, 2005), and each time I was able to see transactions that did not belong to me.

This clearly showed that the API was not verifying whether I actually owned the account I was requesting.

Step 4: Accessing Other Users' Account Details

After confirming I could access transactions, I moved on to retrieving full account details:

GET {{baseUrl}}/api/v1/accounts/:account_id

By simply changing the account_id, I was able to view sensitive information belonging to other users, including account numbers, routing numbers, balances, credit limits, and even partial SSN data.

At this point, it was clear that not only was authorization missing, but the API was also exposing far more data than necessary.

OWASP API1:2023- Broken Object Level Authorization (BOLA)

OWASP API3:2023- Broken Object Property Level Authorization (BOPLA)

Step 5: Manipulating Account Balances (Critical Impact)

This is where things became much more serious.

Since I could access other users' accounts, I tested whether I could also modify them:

PUT {{baseUrl}}/api/v1/accounts/:account_id

I targeted account 2002 and changed the balance:

• From its original value → 5,000,000

• Then increased it further → 9,000,000

I repeated the same action on account 2003, successfully setting its balance to 9,000,000.

All changes were accepted by the API and reflected immediately when I retrieved the account again.

This confirmed that I wasn't just viewing data, I had full control over it.

At this point, the vulnerability escalates from data exposure to financial manipulation.

OWASP API1:2023 — Broken Object Level Authorization (BOLA)

OWASP API3:2023 — Broken Object Property Level Authorization (BOPLA)

Step 6: Listing All Accounts

I then called:

GET {{baseUrl}}/api/v1/accounts

Instead of limiting results to my own accounts, the API returned multiple accounts, further confirming weak access control.

OWASP API1:2023- Broken Object Level Authorization (BOLA)

Step 7: Privilege Escalation via Profile Update

OWASP API3:2023- Broken Object Property Level Authorization (BOPLA)

Next, I explored whether I could modify my own profile:

PUT {{baseUrl}}/api/v1/profile

In the body of the request, I included:

{
"role": "admin"
}

The request returned a success response. To confirm, I fetched my profile again and my role had been updated from customer to admin. There were no restrictions preventing me from modifying a sensitive field like role.

This is a classic case of mass assignment leading to privilege escalation.

Step 8: Accessing Admin-Only Endpoints

With my new privileges, I attempted to access admin endpoints:

GET {{baseUrl}}/api/v1/admin/accounts

The API returned a full list of accounts without any restriction.

This confirmed that the system trusted my modified role without performing deeper authorization checks.

OWASP API5:2023- Broken Function Level Authorization (BFLA)

Step 9: Retrieving All Users and Hashed Passwords

Finally, I accessed:

GET {{baseUrl}}/api/v1/admin/users

This returned a complete list of users, including:

• Email addresses
• Full names
• Roles
• Hashed passwords

[
    {
        "id": 1001,
        "email": "alice@ovb.com",
        "full_name": "Alice Johnson",
        "role": "customer",
        "hashed_password": "[REDACTED]",
        "created_at": "2026-04-23T07:24:18.254722"
    },
    {
        "id": 1002,
        "email": "bob@ovb.com",
        "full_name": "Bob Smith",
        "role": "customer",
        "hashed_password": "[REDACTED]",
        "created_at": "2026-04-23T07:24:18.254731"
    },
    {
        "id": 1003,
        "email": "carol@ovb.com",
        "full_name": "Carol Williams",
        "role": "customer",
        "hashed_password": "[REDACTED]",
        "created_at": "2026-04-23T07:24:18.254732"
    },
    {
        "id": 1004,
        "email": "admin@ovb.com",
        "full_name": "System Admin",
        "role": "admin",
        "hashed_password": "[REDACTED]",
        "created_at": "2026-04-23T07:24:18.254733"
    },
    {
        "id": 1005,
        "email": "user@mail.com",
        "full_name": "User Me",
        "role": "admin",
        "hashed_password": "[REDACTED]",
        "created_at": "2026-04-23T09:20:40.300230"
    },
    {
        "id": 1006,
        "email": "user1@mail.com",
        "full_name": "User Me",
        "role": "customer",
        "hashed_password": "[REDACTED]",
        "created_at": "2026-04-23T09:26:40.674028"
    }
]

At this stage, the entire system was effectively exposed.

OWASP API5:2023- Broken Function Level Authorization (BFLA)

OWASP API2:2023- Broken Authentication

Impact

By chaining these vulnerabilities together, I was able to:

• Access other users' financial data
• Modify account balances arbitrarily
• Escalate privileges from a "customer" to "admin"
• Retrieve all users and hashed passwords
• Achieve full control over the system

Conclusion

This exercise clearly shows how dangerous poorly secured APIs can be. What started as a simple test of endpoints quickly turned into a full system compromise. The lack of proper authorization checks, combined with excessive data exposure and insecure input handling, made it possible to move from a normal user to full administrative control.

Recommendations

• Enforce strict object-level authorization checks
• Prevent modification of sensitive fields like 'role'
• Implement proper role-based access control (RBAC)
• Limit sensitive data exposure in API responses
• Validate and whitelist user inputs
• Monitor and log suspicious activity

This wasn't just about finding bugs, it really showed me how small gaps in API security can quickly turn into major vulnerabilities when chained together.