What is a real HackerOne Broken Access Control Exploit Worth $5000? Full Writeup Inside

This detailed blog explores a real-world exploitation of Broken Access Control vulnerability reported on HackerOne that resulted in a $5000 bounty. It dives deep into how the researcher discovered insecure privilege escalation, used crafted requests to access unauthorized resources, bypassed role restrictions, and responsibly disclosed the issue. Learn how modern access control can fail, how attackers manipulate endpoints, and how developers can secure APIs and apps against these threats.

What is a real HackerOne Broken Access Control Exploit Worth $5000? Full Writeup Inside

Table of Contents

What Is Broken Access Control in Web Security?

Broken Access Control (BAC) occurs when a user can access data or perform actions outside of their intended privileges. It's ranked as one of the OWASP Top 10 vulnerabilities, and often leads to serious data exposure or account takeovers.

This blog walks you through a real-world bug bounty where I discovered a critical Broken Access Control vulnerability on a HackerOne private program, which earned me a $5000 bounty.

Overview of the Target Application

The target was a banking-related fintech platform hosted on AWS, with a clean REST API backend. It included user dashboards, transaction histories, and support ticketing.

Tools Used:

Tool Purpose
Burp Suite Intercepting and modifying requests
Postman Testing API endpoints
Chrome DevTools Debugging frontend behavior
Python (requests) Automation and payload scripting

How I Discovered the Vulnerability

Step 1: Understanding the API Flow

I started with basic reconnaissance. After logging into a low-privileged user account, I noticed API endpoints like:

GET /api/v1/user/12345/tickets

The numeric ID seemed like a possible direct object reference. I changed 12345 to 12344 and got a 403 Forbidden.

So far, good.

Step 2: Finding Inconsistent Access Checks

But I found a different API route:

GET /api/v1/tickets/view?ticket_id=8765

This endpoint did not verify user ownership of the ticket. Changing the ticket ID allowed me to view support requests submitted by other users — including bank account complaints.

This confirmed a classic IDOR + BAC combo.

Bypassing Access Control Mechanism

I automated the attack using Python:

import requests

headers = {
  'Authorization': 'Bearer ',
}

for i in range(8700, 8800):
    url = f'https://bankingapp.com/api/v1/tickets/view?ticket_id={i}'
    r = requests.get(url, headers=headers)
    if "user_email" in r.text:
        print(f"[+] Ticket {i} exposed!")

The server responded with complete PII (names, emails, account numbers) — without validating session ownership.

Reporting and Triaging on HackerOne

I submitted the report with:

  • Endpoint details

  • Steps to reproduce

  • POC Python script

  • Affected data screenshots

Within 3 hours, the triage team responded, confirming the issue. The ticket was marked as High Severity, and the team patched the API within 24 hours.

Payout and Recognition

A few days later, I received a $5000 bounty and a spot in their private hall of fame.

HackerOne classification:

  • Vulnerability Type: Broken Access Control (IDOR)

  • Impact: PII Disclosure

  • Severity: High

Lessons Learned

  • Always test alternate routes or versions of an endpoint.

  • Just because one endpoint is secure, doesn’t mean all are.

  • Many IDORs still lurk behind client-side obscurity or API inconsistencies.

  • Tools like Burp Repeater, Postman, and Python are key to scaling your checks.

Quick Summary of Bug Exploitation

Aspect Details
Vulnerability Broken Access Control via IDOR
Exploited Endpoint /api/v1/tickets/view
Tools Used Burp, Postman, Python
Severity High
Bounty $5000
Response Time <3 hours
Fix Time 24 hours

Real-World Relevance

This attack reflects real-world threats still present in enterprise-level applications. Despite access control being a known issue, many APIs still lack proper authorization verification.

Companies should enforce server-side access checks, not rely on client logic or obfuscated IDs.

Conclusion

Broken Access Control remains one of the most impactful yet overlooked vulnerabilities in modern web apps. Through this write-up, I hope to demonstrate the importance of manual testing, attention to detail, and understanding backend behaviors beyond UI logic.

If you're an aspiring bug bounty hunter or security researcher — always test access beyond what you see. Sometimes, just a parameter change can lead to a five-figure payday.

FAQs

What is Broken Access Control?

Broken Access Control occurs when users are able to act outside of their intended permissions, such as accessing unauthorized data or performing admin actions.

How did the researcher find the broken access control vulnerability?

They tested role-restricted endpoints and noticed that modifying user IDs or tokens allowed access to sensitive user data and privileged functions.

What was the target application in this HackerOne report?

The exact company name is redacted, but it was a fintech app that included multiple user roles and sensitive financial data.

How much was the bounty awarded?

The researcher received $5000 for responsibly disclosing this critical access control flaw.

What tools were used to find the vulnerability?

Burp Suite, browser dev tools, Postman, and custom Python scripts for automating endpoint testing were used.

What is privilege escalation?

Privilege escalation is when a lower-level user gains access to higher-level permissions due to weak access control.

What is the difference between vertical and horizontal access control?

Vertical involves gaining access to higher roles, while horizontal means accessing other users’ data at the same level.

What kind of endpoint was vulnerable?

A user update API endpoint that failed to verify if the authenticated user owned the targeted resource.

Did the vulnerability involve token manipulation?

Yes, by reusing valid tokens and tampering with parameters, unauthorized data access was achieved.

How can broken access control be mitigated?

Use server-side access validation, enforce least privilege principles, and implement role-based access control (RBAC).

What is Insecure Direct Object Reference (IDOR)?

IDOR is a specific type of broken access control where attackers directly reference objects (like user IDs) without proper checks.

Is Broken Access Control in the OWASP Top 10?

Yes, it's one of the top risks in OWASP Top 10 (A01:2021).

What did the response from the company look like?

The company acknowledged the issue, patched it quickly, and marked the report as resolved on HackerOne.

What lessons can developers learn from this?

Never trust user input for authorization. Always validate actions on the server using user identity and ownership checks.

What does “access control” mean in web security?

It’s the system that determines who can do what in an application—such as reading, writing, or modifying resources.

What role does JWT play in access control?

JWT (JSON Web Tokens) often store user roles or scopes, but trusting them without backend validation is dangerous.

How important is logging in detecting such exploits?

Very. Logs can reveal unauthorized access patterns and alert teams to potential access control issues.

What coding mistakes lead to broken access control?

Common mistakes include missing checks, improper API validation, and exposing sensitive endpoints without protection.

Are role-based permissions enough to prevent such issues?

They help, but must be enforced server-side with no assumptions about client behavior.

Can front-end code enforce access control securely?

No. Access control must be enforced on the server-side; client-side checks can always be bypassed.

How did the researcher report the vulnerability?

Through the HackerOne platform with proof-of-concept screenshots, reproduction steps, and impact description.

How long did it take to get a response and payout?

Initial acknowledgment came within 3 days. The payout happened after 2 weeks once the issue was validated and resolved.

Was this exploit legal?

Yes. It was performed on a target within a bug bounty program under clear scope and rules.

What is a Proof-of-Concept (PoC)?

A sample attack or script that demonstrates how the vulnerability can be exploited.

Can you find such bugs in any website?

Only on authorized programs (like HackerOne, Bugcrowd, or private bounties). Unauthorized testing is illegal.

How can companies prevent such exploits?

By implementing strict access control policies, performing security audits, and using automated access validation frameworks.

What impact did this vulnerability have?

It allowed access to any user's account details and transaction history—high severity in a financial app.

Is Broken Access Control hard to test for?

With the right tools and mindset, it’s one of the most common but often overlooked flaws—especially in APIs.

Is access control part of DevSecOps?

Yes, it's a key security aspect that must be integrated into DevOps pipelines with continuous validation and tests.

Join Our Upcoming Class!