Two questions: authentication and authorization

Almost every access-control bug in the world comes from a system confusing two questions that sound similar and are completely different. Get the distinction clear now, in this first lesson, and the rest of the path is variations on a theme.

Authentication: who are you?#

Authentication is proving identity. It is the login form, the password, the second factor, the session cookie, the API token. When you type your password and the site accepts it, you have been authenticated: the server now believes it knows who you are. Everything in Foundations about identity being a value you send lives here, the cookie or token that says "I am this user" is the result of authentication.

Authentication can fail in obvious ways (a weak password, a login you can brute force) and subtle ones (a token you can forge, a reset link you can steal). The later lessons in this path go after all of those. But even perfect authentication only answers the first question.

Authorization: are you allowed to do this?#

Authorization is the second question, asked after identity is known: given that you are this user, are you allowed to do the specific thing you are asking to do? Read this invoice, delete this comment, reach this admin page, change this account's role.

This is where the money is. A site can know exactly who you are, flawless login, strong passwords, real two-factor, and still hand you another customer's data, because knowing who you are is not the same as checking what you may touch. The order lab in Foundations was pure authorization failure: you were properly logged in as yourself, and the server still gave you a stranger's order, because it authenticated you and then forgot to authorize the specific request.

Why the confusion is so common, and so costly#

Developers build the login first. It is visible, it is obviously security, everyone remembers it. Authorization is invisible and per-request: every single endpoint has to independently ask "does this user own this object?" and it is desperately easy to forget on the fortieth endpoint at 5pm. The login looks done, the app looks secure, and meanwhile half the API trusts whoever is asking.

So the two failure shapes you will hunt are:

• Broken authentication: you become someone you are not, or get in without proper proof. Default credentials, brute force, a forgeable token, a stealable reset link.
• Broken authorization: you are correctly yourself, but you reach something that is not yours. Object-level (IDOR: another user's object) and function-level (BFLA: an action meant for admins).

The industry names them the same way. OWASP puts broken access control at the very top of its list of web risks, precisely because authorization is forgotten so often and the impact is so direct.

Two flavours of authorization, named now#

You will meet both repeatedly, so learn the names here:

• Object-level authorization asks "does this user own this specific object?" Failing it is IDOR (Insecure Direct Object Reference) or, in API language, BOLA (Broken Object Level Authorization). The order lab was this.
• Function-level authorization asks "is this user's role allowed to perform this action at all?" Failing it is BFLA (Broken Function Level Authorization), a normal member reaching an admin-only endpoint.

Lessons 3 and 4 are these two, in order.

The honesty gate, restated#

Because this path is about reaching things that are not yours, keep the gate from Foundations in front of you the whole time: it is only a finding if you reach another user's data or a privileged action you should not have. Reading your own invoice by its id is not a bug. Reading data that is deliberately public is not a bug. Reaching the admin function as an admin is not a bug. The finding is the boundary crossed, and the whole skill is proving you crossed one you were not meant to. On a real target you demonstrate that with two accounts you own, never with a stranger's real data.

Where this goes next#

You now have the two questions and the vocabulary. The next lesson builds the single most important tool for testing authorization: the two-account method, a harness so simple and so powerful that experienced testers reach for it before anything else.