$500 Broken Access Control Bug: Unauthorized Removal of Private Pension Schemes

October 25, 2025 • 7 min read

A deep dive into how an accountant role bypassed role-based access control to delete private pension schemes via direct API calls - and how developers can prevent it.

Disclaimer:
This write-up analyzes a vulnerability discovered by another independent researcher.
It is shared for educational, defensive, and awareness purposes only - not to replicate exploitation.
Our mission is to help developers and security professionals learn how to detect, mitigate, and prevent similar access-control issues.

Introduction

In early 2025, a security researcher discovered a Broken Access Control (BAC) vulnerability on FinManageHub, a payroll and HR management SaaS platform.
The flaw allowed users with the accountant role - who were not authorized to manage pension schemes - to delete all private pension configurations by directly invoking a backend API.

This bug bypassed the Role-Based Access Control (RBAC) system, leading to a $500 payout ($300 bounty + $200 bonus) for its severity and impact.

What makes this case worth studying is not just the payout - but the lesson it teaches about the dangers of trusting client-side restrictions.
Let’s walk through the scenario, how the vulnerability was found, its business impact, and how both security researchers and developers can learn from it.

Conceptual image showing a user gaining unauthorized access to a restricted pension management dashboard, bypassing intended security controls.

Understanding the Target: FinManageHub

FinManageHub is a cloud-based HR and payroll management platform.
Its purpose is to simplify operations for organizations by providing modules for:

Payroll processing
Benefits and pension management
Employee record handling
Role-based access and reporting

🧩 Role Architecture Overview

FinManageHub uses a role-based permission model (RBAC) with the following tiers:

Admin - Full control over all company configurations.
HR Manager - Manage employee data and benefits.
Accountant - Access payroll and financial reports, but no modification rights for benefits or pensions.
Employee - View-only access for personal data.

The system’s UI strictly enforced these permissions. For example, when logged in as an accountant, the “Pension Management” panel appeared greyed out - preventing direct interaction.

However, as the researcher rightly questioned:

“If the UI blocks it, does the backend actually enforce the same restriction?”

The Vulnerability: API Authorization Bypass

The real issue wasn’t in the interface - it was in the backend.

When the researcher inspected API calls via Burp Suite while logged in as an accountant, they noticed the application communicating with a pension-related endpoint:

POST /payroll-v2/v1/public/jetlang/commands/save-company-action/915
Host: api.finmanagehub.com
Authorization: Bearer <accountant-token>
Content-Type: application/json


{
  "companyId": "YOUR-COMPANY-ID",
  "absoluteMonth": 104,
  "updates": {
    "variables": {
      "06.735": { "104": 0 }
    }
  },
  "updateInPastEnabled": false
}

To their surprise, even though the accountant role was restricted in the frontend, this API request executed successfully - deleting all private pension schemes associated with that company.

No server-side validation was performed to confirm whether the requesting user was authorized to modify pension settings.
This is a textbook Broken Access Control (specifically, a Role-Based Access Control (RBAC) bypass) issue.

Visualization of a malicious API request successfully bypassing security checks, leading to an authorization bypass.

Root Cause: Insecure Direct API Call (IDAC)

This vulnerability falls under a variant known as Insecure Direct API Call (IDAC) - where backend APIs rely solely on the presence of a valid token without verifying what role or permissions that token represents.

❌ What Happened Internally

The frontend applied role restrictions - “Accountants can’t manage pensions.”
The backend API, however, trusted the JWT token blindly.
There was no secondary authorization check to validate user role before executing a destructive operation.

Essentially, the API logic assumed:

“If the request comes from a valid token, it’s allowed.”

This misplaced trust led to a critical authorization flaw.

Security Impact

Let’s unpack why this vulnerability was severe enough to earn a $500 reward.

🚨 1. Unauthorized Data Modification

An accountant could modify or delete private pension schemes - a sensitive component of the payroll system.

⚖️ 2. Compliance Risks

Many jurisdictions (like the UK, EU, and India) have strict labor and financial regulations around pension schemes.
Unauthorized deletion could violate:

GDPR (Data integrity principle)
Labour Welfare Acts (mandated benefits)
SOX (for publicly listed companies)

💸 3. Financial & Business Impact

Removing pension schemes could:

Interrupt automatic salary deductions.
Lead to employee benefit losses.
Create audit discrepancies and mistrust.

🕵️ 4. Audit Failures

Since this action bypassed the UI, the changes might not be recorded in standard UI-driven audit logs - meaning no traceability.

Illustration depicting various compliance and financial risks, such as data breaches, regulatory fines, and monetary losses, resulting from an access control vulnerability.

Lessons Learned

🧠 1. The UI Is Not a Security Layer

User interfaces are cosmetic controls - they can guide behavior but cannot enforce rules.
Attackers can bypass UIs using:

Burp Suite or Postman to replay/modify requests
Custom cURL commands
Mobile app traffic interception

Never assume that if a button is hidden, the function behind it is safe.

🧩 2. Always Test APIs Directly

If you’re testing an application (legally via bug bounty or permission):

Intercept network calls via Burp Suite or ProxyMan.
Replay API endpoints using the same JWT token.
Observe response codes (200 vs 403).
Test privilege boundaries (e.g., accountant token vs admin token).

You’d be amazed how often the backend forgets to verify roles.

🔐 3. Enforce Authorization Server-Side

All backend endpoints must verify who is making the request and what role they belong to.
Here’s a simple pseudocode pattern:

def delete_pension_scheme(user, scheme_id):
    if user.role != 'Admin' and user.role != 'HR':
        raise UnauthorizedError("You are not permitted to modify pensions.")
    # Proceed with deletion

Authorization must be a server-side check, not a UI toggle.

⚙️ 4. Apply Principle of Least Privilege

Limit API token capabilities:

Each role’s token should be scoped to its permitted operations.
Sensitive endpoints (like pensions, salaries) must explicitly require admin scopes.

"scopes": [
  "read:payroll",
  "write:employee",
  "manage:pension" // Only for admin tokens
]

🧾 5. Comprehensive Audit Logging

To detect abuse:

Log who, when, and what was modified.
Store logs separately from the main database.
Alert on destructive operations (e.g., pension removal).

LOG: [WARNING] UserID=4532 Role=Accountant deleted pension_scheme_id=735 at 2025-05-02T13:41Z

Such logs make it easier to detect anomalies early and respond to incidents.

🧱 6. Defense in Depth

Combine multiple layers of protection:

Layer	Example
Frontend	Hide restricted UI options
Backend	Enforce RBAC checks
API Gateway	Validate tokens and permissions
SIEM	Detect unauthorized API calls
Rate Limiter	Throttle repeated modification attempts

The more cross-checks, the harder it is for attackers to succeed.

Graphic showing the distinct layers of frontend and backend validation, emphasizing the critical importance of server-side checks for security.

Developer’s Perspective: Fixing BAC Flaws

Here’s a quick checklist for developers and architects designing secure APIs:

Control Area	Action
Authentication	Use JWTs or OAuth2 tokens with strict scopes
Authorization	Enforce role validation in every endpoint
Input Validation	Don’t trust client-side data like role or companyId
Least Privilege	Restrict sensitive operations to admins
Audit Logging	Record all destructive or privilege-changing actions
Error Handling	Use consistent 403/401 messages, avoid verbose errors
Security Testing	Include RBAC validation in automated CI/CD tests

Even if your app uses frameworks like Django, Spring, or Laravel, ensure middleware-level access control is active for each route.

Diagram comparing a secure API authorization flow with an insecure one, highlighting the differences in validation and access control mechanisms.

For Bug Hunters: Testing BAC & IDAC Vulnerabilities

🧩 Step-by-Step Ethical Testing Flow

Log in as a low-privilege role (e.g., accountant).
Capture requests while performing restricted actions.
Send requests to Repeater in Burp Suite.
Replace your token with another role’s token or replay your own request.
Observe responses - 200 OK indicates possible access control issue.
Report responsibly with detailed reproduction steps.

🛠️ Tools to Enhance Testing

Burp Suite / OWASP ZAP - For manual proxy testing.
Autorize (Burp Extension) - Automatically compare authorized vs unauthorized sessions.
Postman / cURL - For manual endpoint replay.
jwt.io - Decode and inspect JWT claims.

Symbolic image combining a security patch icon with audit logs, representing the remediation and monitoring efforts after discovering an access control vulnerability.