Welcome to our Pentest Files series. Each post presents a real, interesting or dangerous finding one of our testers has identified during an actual engagement, so you can see the kinds of things our pentesters get up to, and take steps to prevent similar vulnerabilities in your own assets. Findings are taken from real reports, anonymised, and published with kind permission from our clients.

The Finding

Vulnerability type: Privilege Escalation via Broken Object-Level Authorisation (BOLA)

Severity: High

Discovered by: Nabeel Ahmad, OnSecurity

The Setup

The target was a web application used by schools to manage communications with parents and staff. Like many platforms of its kind, it operated on a multi-tenant model, with each school having its own isolated environment and a clearly defined hierarchy of user roles. Parents sat at the bottom of that hierarchy. Administrators sat firmly at the top, behind a dedicated login portal.

Nabeel started where any tester would: by poking at what a low-privileged user could actually see and do. Logging in as a parent account, he navigated to the admin panel at /admin/auth/login. As expected, the application pushed back — an error message, insufficient permissions, nothing to see here.

Most users would stop there. Nabeel didn’t.

Instead of accepting the front-end rejection at face value, he opened up his proxy tool and started watching the traffic more carefully. If the application was going to say no, he wanted to understand how it was saying no — and whether that refusal was actually being enforced where it mattered.

The Exploit

What followed was a clean, methodical attack chain. No exotic tooling required, just a proxy, some curiosity, and a good understanding of how invitation-based access systems tend to work.

Step 1 — Capture the authentication tokens

During login, Nabeel intercepted the POST request to /api/auth/firebase-token. The response came back with two critical pieces of information: a Bearer token for the authenticated session, and a x-tenant header containing the tenant’s unique ID (a UUID tied to the school’s environment).

POST /api/auth/firebase-token?fbAuthToken=... HTTP/2
Host: api.example.com

→ Response: Bearer [token], X-Tenant: {tenant-id}

Step 2 — Query the invitation codes endpoint

With token and tenant ID in hand, Nabeel crafted a direct API request to an endpoint that, by all rights, should have been off-limits to a parent account:

GET /api/invite_codes/tenant/{tenant-id}?limit=1000&page=1 HTTP/2
Host: api.example.com
Authorization: Bearer [parent token]
X-Tenant: {tenant-id}

The server responded with a 200 OK and a full list of pending invitation codes for the tenant. There were no server-side checks to confirm whether the requesting user was an administrator. The endpoint simply trusted that if you had a valid token and knew the tenant ID, you were entitled to see the data.

Step 3 — Register an admin account

Armed with an active invitation code, Nabeel used an email address under his control to register a new account. The invitation code carried with it the elevated permissions it was originally intended to grant, in this case, admin access.

Step 4 — Log in as an administrator

With the newly created account, Nabeel walked straight through the admin panel login that had turned him away moments earlier. Full administrative access, achieved without ever needing to know an admin’s credentials, exploit a session, or bypass any cryptographic controls. The front-end restriction had been meaningless because the underlying API never enforced the same rules.

Why This Is Dangerous

This kind of vulnerability, where server-side authorisation doesn’t match what the front end promises, is one of the most impactful classes of web application flaws. In this context, the consequences were significant:

• Unauthorised admin access: Any parent with a valid login could have escalated themselves to full administrator, giving them control over the entire school tenant.
• Data exposure: Admin panels typically expose sensitive data — in a school platform, that means student records, staff information, communications, and safeguarding-relevant data.
• Configuration and integrity risk: An attacker with admin access could alter system settings, manipulate user accounts, disable legitimate administrators, or disrupt the service entirely.
• Silent exploitation: Because the attack used legitimate API functionality rather than anything obviously malicious, it would leave little trace in standard application logs. It would be difficult to detect after the fact.
• Scalable across tenants: If an attacker could identify tenant IDs for multiple schools on the platform, not a difficult task given they’re exposed in normal traffic, the same technique could be replicated across the entire customer base.

The Remediation

The fix here isn’t complicated in concept, but it does require discipline in implementation. The root cause was the API treating authentication (are you logged in?) as equivalent to authorisation (are you allowed to do this?). They’re not the same thing, and every sensitive endpoint needs to check both.

Specific recommendations:

• Enforce role-based access control server-side on every API endpoint. The invitation codes endpoint should verify that the requesting user holds an administrative role before returning any data. Front-end restrictions are cosmetic; they can always be bypassed by anyone with a proxy.
• Scope invitation codes to specific recipients. Codes should be tied to a target email address at the point of creation and validated against that address at the point of redemption. A code intended for [email protected] should be worthless in anyone else’s hands.
• Audit and rotate exposed invitation codes. Any codes that were active during the window of vulnerability should be treated as potentially compromised and invalidated immediately.
• Review access logs for signs of prior exploitation. Look for non-administrative accounts making requests to admin-scoped API endpoints, particularly the invite codes endpoint.
• Apply the principle of least privilege consistently across your API surface. If a parent account has no legitimate reason to call an endpoint, that endpoint should return a 403 for a parent account, every time, without exception.

Once fixes are in place, OnSecurity provides free retesting as standard, so clients can validate that the vulnerability has been fully resolved and nothing has been missed. In this case, retesting confirmed the endpoint now correctly returns a 403 Forbidden response for non-administrative users.

Closing Thoughts

This finding is a good reminder that access control isn’t just about what your UI shows – it’s about what your API allows. The admin panel login page said no. The API said yes. And in a conflict between the two, the API always wins.

A real attacker with a parent account and a proxy tool could have found this in minutes. Nabeel found it first, documented it clearly, and gave the client the chance to fix it before anyone else got there.

That’s exactly what penetration testing is for.

If you manage a multi-tenant SaaS platform, a school application, or any system with role-based access controls, it’s worth asking: are your API endpoints enforcing the same rules your front end promises? The answer might surprise you.

OnSecurity’s real-time reporting platform means you see findings like this as they’re discovered, not weeks later in a static PDF. Every issue, every step of the exploit, and every recommendation is available the moment it’s written up.

Want to know if your application is vulnerable to similar issues? Get a quote from OnSecurity and find out what your attackers might already know.