Permission and Authorization Bugs

When an application looks up a resource by ID without verifying the requesting user owns or is permitted to access that specific record, any authenticated user can read, modify, or delete another user's data by supplying the other user's resource ID. This is an Insecure Direct Object Reference (IDOR) vulnerability.

When a button or action is hidden from lower-privileged users in the UI, but the underlying API endpoint does not enforce the same permission server-side, the restricted action can be executed by any authenticated user who calls the API directly. Authorization is only enforced at the presentation layer, not on the server.

Any authenticated user can promote their own account to admin by including a 'role' field in the body of a PATCH /api/users/me request. The endpoint deserialises the entire request body onto the user record without an allowlist, so the role field is treated as a normal updatable field rather than a protected one.

After an administrator deletes or disables a user account, that user's existing bearer token continues to authenticate successfully and passes authorisation checks on protected endpoints. The authentication middleware verifies only the token's signature and expiry — it never queries the database to confirm the account still exists and is active.

An admin-only page is hidden from the navigation for normal users, but the route itself has no server-side authorization. A non-admin who navigates directly to the admin URL can load the page and, often, perform admin actions — because access control was applied to the menu, not the route or its APIs.