IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
OWASP API Top 10 — how APIs get attacked
Most API breaches are not clever. A permission check was simply missing. Here is a tour of the identity-related risks from the OWASP API Security Top 10. It is told as attacks on Maya's pilates-booking API. Your goal: spot these risks before an attacker does.
- BOLA: the API never checks that the caller owns the object. This is the top risk.
- Property level: a caller can write fields they should not, such as
role. - Function level: a powerful route has no server-side role check.
- Also: no rate limit, and over-trusting other APIs.
#1: Broken Object Level Authorization (BOLA)
Maya's app reads her booking with GET /bookings/1001. It works. An attacker changes one digit: GET /bookings/1002. Now they read Sam's booking, with Sam's name and phone. The API checked that the token was valid. It never checked that this caller owns this object. Think of a railway TTE who checks that your ticket is real, but not that it is for this seat.
The fix is a per-object check on every request: does Maya own booking 1002? No, so return 403. A graph answers this well (see permissions as a graph). When the object belongs to another customer, it is cross-tenant access (see tenant isolation).
Maya reads booking 1001. Out of curiosity, she edits the URL to 1002. There is Sam's class and Sam's phone number. It was the same token and a different object. The server never asked if it was hers.
#2: Broken Authentication
If tokens can be forged or guessed, or never expire, everything else falls. Weak signing, no expiry and no audience check are typical causes. The attacker does not even need to change IDs. They make up any identity they like. See how tokens are born.
#3: Broken Object Property Level Authorization
Maya updates her profile with PATCH /users/me {name: "Maya"}. That is fine. But the endpoint copies every field of the body into the record. So an attacker sends {role: "admin"} and promotes themselves. This flaw is called mass assignment. The question is which properties a caller may write: name yes, role no. The fix is a server-side allow-list of writable fields.
The read-side twin is excessive data exposure. The reply includes fields the caller should never see, such as a password hash. Return only what the client needs.
More of the tour
🌊 #4: Unrestricted resource consumption
One key sends 10,000 requests a minute, and the database gives up. The defense is the rate limits and quotas from the gateway lesson. The reply is 429, not a crash.
🚪 #5: Broken Function Level Authorization
The /admin/refunds route is only hidden by the app screen. A normal user's token calls it directly and gets 200. Every powerful function needs a role check on the server. A hidden button is not a check. A "Staff only" sign on a door with no lock keeps nobody out.
🔗 #10: Unsafe consumption of APIs
Your booking API trusts a partner calendar's reply and stores its unchecked data. Treat other APIs like any outside input. Validate it, limit it, and do not over-trust it.
Go deeper: names, and the other four risks
The newest edition of the OWASP API Security Top 10 is still the 2023 list. Some people call BOLA by an older name, IDOR (insecure direct object reference). BOLA is the OWASP name.
Four more entries are covered in more ways APIs break, in the API security track. They are API6 sensitive business flows, API7 server-side request forgery (SSRF), API8 security misconfiguration and API9 improper inventory management.
🧪 Interactive lab — enable JavaScript to play with this one.
Building on GraphQL? Grade your schema's depth, introspection and object access with GraphQL Check. Or talk to our team about an API authorization review.