API Security

Because APIs usually authenticate correctly but fail to check whether the authenticated user may touch a specific object or action. You log in as an ordinary user, then reach other users' objects or admin-only functions because no per-request ownership or role check runs. That is the core of the OWASP API Top 10.

BOLA, Broken Object Level Authorization, is when an endpoint returns an object by id without checking you are allowed to see it. It is common because the exploit is just changing the id, and developers often add the id lookup but forget the ownership check. It is the top risk in the OWASP API Top 10.

No. A JWT's header and payload are base64url-encoded, not encrypted, so anyone can decode and read the claims. That is harmless. The vulnerability is a server that trusts a token without properly verifying its signature, for example by accepting an alg:none token.

Mainly curl to send precise HTTP requests and jq to read JSON responses. With those you can enumerate endpoints, inspect every field and token, and read status codes. Everything in this first lesson runs against your own lab API or an in-scope program.

Mass assignment is when an API binds your entire JSON body onto an object, including fields you should never control such as role or is_admin. Adding such a field can escalate privilege. The fix is a server-side allow-list that maps only the fields a user is permitted to set.

A grid with every endpoint on one axis and every identity on the other, for example user A, user B and no token, with the server's status code in each cell. Cells where a user reaches another user's object or a role-restricted action flag BOLA and BFLA candidates, which you then confirm by comparing response bodies.