Access Control Study Portal

A: When the application exposes a reference to an internal object (a database key, filename, or user ID) in a request and authorizes the action based on the reference existing rather than on the requester's right to that object, so an attacker can change the value to access data that isn't theirs.

A: Authentication establishes who you are (login, MFA, tokens); authorization establishes what you are allowed to do (read this record, invoke this function). Broken Access Control is overwhelmingly a failure of authorization, not authentication.

A: Acting as a different user at the same privilege level — for example one customer reading or modifying another customer's order. It is the typical outcome of IDOR.

A: Gaining a higher privilege level than assigned — for example a normal user invoking an admin-only endpoint, reaching /admin, or setting their own role to admin via a trusted request field (mass assignment).

A: Because the control must be enforced on the server on every request; the UI runs on the attacker's machine. They can call the endpoint directly with curl/Postman regardless of what the page renders, so UI-only checks protect nothing.

A: Every resource is forbidden unless a rule explicitly allows it, so newly added or forgotten endpoints are safe by construction. It converts the most common mistake — forgetting to add a check — from a data breach into a harmless 403.

A: Fold the authorization predicate into the data lookup itself — query for the order scoped to the authenticated user (WHERE id = :id AND owner_id = :sessionUserId) and return 404 if nothing matches, deriving the user ID from the session/token, never from the request.

A: RBAC grants permissions through roles assigned to users (coarse, simple, auditable); ABAC computes decisions from attributes of subject/resource/action/environment (fine-grained, context-aware, harder to audit). RBAC alone usually can't express resource ownership, which is where IDOR hides.

A: They are obscurity, not access control — IDs leak through logs, Referer headers, browser history, shared links, and APIs. They raise the cost of guessing but the server must still verify the requester's right to the object on every request.

A: Directly requesting URLs that were never linked — /admin, /api/internal/..., backup or metadata files — to find unprotected functionality. It defeats apps that rely on a path being secret instead of on an enforced authorization check.

A: Every principal (user, service account, token, DB connection) is granted the minimum permissions required for its task and nothing more, ideally time-bounded, so a compromised or misused credential can do limited damage.

A: Reflecting the request's Origin into Access-Control-Allow-Origin while also sending Access-Control-Allow-Credentials: true lets an attacker's site make authenticated cross-origin requests as the victim and read the responses, effectively bypassing the same-origin protection around authorized data.

A: If the token's signature, issuer, audience, and expiry aren't verified — or the alg:none downgrade is accepted — an attacker can forge or tamper with claims like role:admin. Even a valid token's claims should be treated as authoritative only after full verification against trusted keys.

A: It is enforcing authorization on each operation/endpoint, not just on data. It breaks when developers protect one verb or route (e.g. GET /admin/users) but forget a sibling (POST/DELETE /admin/users/:id), leaving privileged actions reachable.

A: HTTP is stateless, so each request must independently prove the right to act; a session that was authorized for one action is not implicitly authorized for the next. Checking only at login leaves every subsequent request unguarded.

A: Input like ../../etc/passwd lets a user escape the intended directory and read files outside their permitted namespace — an authorization failure over the filesystem. Mitigate by canonicalizing the path and validating it stays within an allow-listed root.