Modern apps — whether on your phone or the web — talk to hidden backends to fetch your data: grades, orders, appointments, or personal notes. Normally, the app sends a simple number or ID like ?id=123 to tell the server which data to return.
Here’s the catch: if the server trusts that number without checking if you’re actually allowed to see it, hackers can exploit this and grab other people’s private data.
Security experts call this vulnerability Broken Object Level Authorization (BOLA) — or the older term IDOR. In plain language, it’s when someone who’s logged in can access things they shouldn’t, just because the system doesn’t verify ownership.
A Real-World Example: EduPortal
Imagine EduPortal, a learning platform where students track their progress and tutors manage student profiles.
The app fetches a student profile with a request like:
/student-profile?studentId=456456is just the student’s ID.The server checks that the user is logged in (authentication — “Who are you?”).
But it doesn’t check if the user should see that profile (authorization — “What are you allowed to see?”).
If a student changes 456 to 457, they might see another student’s grades, notes, and personal info. Hackers can repeat this trick thousands of times — the numbers are predictable, after all — and collect tons of sensitive data.
How Hackers Pull This Off
Here’s the step-by-step:
Log in with a normal account.
Capture the request the app sends:
GET /api/student-profile?studentId=456
Authorization: Bearer <token>Bearer token: Think of it as a digital key that proves you’re logged in.
Swap the student ID to another number, like 457.
Resend the request. If the server responds with someone else’s data, the system is vulnerable.
Hackers can automate this — loop through hundreds or thousands of IDs to scrape entire databases.
Scraping: Collecting data automatically from a system.
Exfiltrated: Stolen data leaving a system.
Tools Hackers Use
Security testers (and hackers) often use Burp Suite:
It acts as a middleman between your app and the server.
Captures the requests your app sends.
Lets you change IDs and replay requests to see what data comes back.
Can automate the process to test thousands of IDs quickly.
Replay: Sending a request again, often with small tweaks.
Enumerate: Trying all possible options (like sequential IDs) to find valid ones.
Why This Happens
Several design mistakes make this easy:
Predictable IDs: Simple numbers are easy to guess.
No object-level authorization: The server only checks if you’re logged in, not if you own the data.
Too much data returned: Private notes, emails, or other sensitive info get sent when they shouldn’t.
No monitoring: Bulk requests go unnoticed.
Trusting the UI: Just hiding buttons in the app doesn’t stop backend attacks.
OWASP, the organization tracking top security risks, lists this as API1:2023 – Broken Object Level Authorization, the #1 API risk.
Why You Should Care
If you run a SaaS platform — for education, healthcare, or bookings — even a small flaw can leak sensitive data:
Any endpoint taking a client-provided ID is a potential goldmine for hackers.
Multi-tenant platforms are especially at risk: a missing check can expose data across all customers.
Hackers don’t need advanced skills. The system itself makes it easy.
Early awareness protects your users and builds trust.
The Takeaway
Authentication (“Who are you?”) is just the first gate. Authorization (“What can you see?”) is the second gate — and often the forgotten one.
Hackers exploit the gap between these two. Never trust an ID from the client. Always ask:
“If someone changes this ID, will they see something they shouldn’t?”
“What if they iterate through all IDs automatically?”
“Are we only returning data the requester is allowed to see?”
Closing this gap now can save you from major data breaches and protect your users’ trust.
Subscribe to the cyber times newsletter