API security: the OWASP API Security Top 10 and defences

Why APIs need their own security focus

A web page hides much of its logic behind buttons and forms. An API exposes that logic directly: every endpoint, parameter and ID is visible to anyone who looks at the traffic from a mobile app or browser. Attackers do not need clever exploits when they can simply change an ID in a URL and receive someone else’s data. That is why the OWASP (Open Worldwide Application Security Project) publishes a separate API Security Top 10. The current edition is from 2023.

The access-control risks

Three of the top five risks are about authorisation, which shows where real incidents come from.

• API1 Broken Object Level Authorisation (BOLA): the API checks that you are logged in, but not that the object you asked for belongs to you. Changing /orders/1001 to /orders/1002 returns another customer’s order. Fix: check ownership or permission on every object, on the server, on every request. Random IDs (such as UUIDs) make guessing harder but are not a fix on their own.
• API3 Broken Object Property Level Authorisation (BOPLA): the API returns or accepts fields it should not. A profile endpoint returns password hashes, or a user sends "role": "admin" in an update and it is saved (mass assignment). Fix: explicit allow-lists of fields for output and input.
• API5 Broken Function Level Authorisation (BFLA): a normal user can call admin functions, for example by switching GET to DELETE or guessing /admin/ paths. Fix: deny by default and check roles on every function.

@app.get("/api/v1/tickets/<int:ticket_id>")
@require_token(scope="tickets.read")
def get_ticket(ticket_id):
    ticket = db.get_ticket(ticket_id)
    if ticket is None or ticket.owner_id != current_user().id:
        abort(404)                       # do not reveal that it exists
    return {"id": ticket.id, "title": ticket.title, "status": ticket.status}

The other risks in brief

Building and testing defences

1. Inventory: list every API, version, owner and data type. Unknown APIs cannot be protected.
2. Gateway: put APIs behind an API gateway for TLS, authentication, rate limiting and logging. A WAF (Web Application Firewall) helps with generic attacks but cannot understand your object ownership rules.
3. Authorisation in code: check object, property and function permissions in the service itself, with shared, tested helper functions.
4. Validate input against a schema (type, length, range, allowed values) and return only the fields the caller needs.
5. Test: include authorisation tests in CI (Continuous Integration), for example user A must get 404 or 403 for user B’s objects. Run authorised security testing before release.
6. Monitor: log who called what, alert on spikes in 401, 403 and 404 responses, and watch for one client walking through sequential IDs.

Tip: security testing of an API you do not own is illegal in many countries without written permission. Practise on deliberately vulnerable lab applications in an isolated environment.