Topic

Challenge: JWT + RBAC hole

Definition

Role-based access control restricts an authenticated action to identities holding a required role, and a guard hole occurs when a route authorization check is missing, misconfigured, or checks the wrong condition.

In simpler words

Being logged in is not the same as being allowed to do this specific thing. A guard hole is where that second check is missing or wrong.

This challenge reuses the authentication and authorization habits from earlier weeks: the difference between not authenticated and not authorized, and the role guard pattern.

Open official example (opens in new tab)

After this you can

Distinguish not authenticated from not authorized
Spot a route missing a role check it clearly needs
Explain why hiding a control in the client is not a real fix

Where role-based access control holes hide

Definition

A route is vulnerable to privilege escalation when it enforces authentication but omits or misapplies the role or ownership check that should limit which authenticated users may perform that action.

In simpler words

The bug is not about who can log in. It is about who can call this specific admin action once logged in.

The most common hole is a destructive or admin-only route, such as delete, role change, or refund, protected only by a global authentication guard, with no role or ownership check at all.

A subtler hole checks a role but compares against the wrong field, or checks it in a way that can be bypassed by a value supplied in the request body.

Keep in mind

401 means the caller is not known; 403 means the caller is known but not allowed here.
Every destructive or role-sensitive route needs an explicit guard, not only a logged-in check.
Hiding a control in the UI is polish, never the security boundary.

Challenge lab

Bug report

Any logged-in member can delete other users tickets, not just admins.

What is broken

DELETE /tickets/:id only relies on the global authentication guard; there is no role check and no ownership check comparing the ticket to the current user.

Broken snippet

@Delete(':id')
remove(@Param('id') id: string) {
  return this.ticketsService.remove(id);
}
// Global JwtAuthGuard just confirms some valid user is logged in.

Pass criteria

Only admins, or the ticket owner per the product rule, can delete a ticket
A member calling this on someone else ticket receives 403, not 204
The fix lives in a guard or decorator, not a hidden client-side button

Checking your session…

Choose the correct fix

Add an admin-only role decorator and a roles guard to the route so only admins can delete.Hide the delete button in the React UI for non-admins.Add a client-side check that blocks the request before it is sent if the user is not an admin.Require the client to send a role field in the request body and trust that field.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. How should the JWT/RBAC challenge be solved?

Concept

Trust the role encoded in the JWT payload without a guard checking itFilter admin-only actions in the React router before navigationReturn 403 from the service only when req.body.role is missingEnforce roles with RolesGuard and @Roles after JwtAuthGuard authenticates

2. Why is UI hiding insufficient?

Syntax

Bundled JavaScript can be un-minified to reveal the buttonAttackers can call the API directlyReact state can be toggled in the browser devtoolsServer-side rendering leaks the hidden markup anyway

3. Why ignore body.role?

Practical

Attackers can set role: admin in JSONbody.role is overwritten by the ValidationPipe defaultsbody.role is only populated on multipart requestsbody.role duplicates the JWT claim and causes conflicts

4. Is cookie presence enough?

Logic

Yes — an httpOnly cookie cannot be forged by a clientNo — must authenticate identity and authorize roleYes — the cookie is signed, so its presence proves the roleYes — CORS ensures only your app can send the cookie

5. What does JwtAuthGuard contribute?

Concept

It reads the @Roles metadata and compares the roleEnsures a valid user is attached before role checksIt issues a fresh JWT when the old one is near expiryIt sets the httpOnly cookie on successful login

6. Which change secures this admin-only delete route?

Practicalintermediate

@Delete(':id')
remove(@Param('id') id: string) {
  return this.ticketsService.remove(id);
}
// only the global JwtAuthGuard runs

Add @Roles('admin') plus a RolesGuard so a non-admin caller gets 403Read a role field from the request body and reject non-adminsHide the delete button in the React UI for non-adminsAdd a second JwtAuthGuard so the route is guarded twice

7. What status for member calling admin-only delete?

Syntax

403 Forbidden401 Unauthorized405 Method Not Allowed400 Bad Request

8. Can global APP_GUARD cover the challenge?

Logic

Yes — global guards still apply to routes; add @Roles where neededNo — global guards only run on routes without decoratorsNo — APP_GUARD cannot read @Roles set with SetMetadataNo — you must apply @UseGuards on every controller instead

9. What is the teaching goal of the challenge?

Concept

JWTs should carry the role so the client can enforce itGuards should live in the React app for faster feedbackAuthorization can be skipped for authenticated usersServer-side authorization is mandatory

10. Which solution is incorrect?

Practical

Combining RolesGuard with the @Roles decoratorRunning JwtAuthGuard before the role checkTrusting a role field the client sends in the JSON bodyReturning 403 when the role is insufficient

11. What enforces that only admins reach setStatus?

Conceptadvanced

@Roles('admin')
@Patch(':id/status')
setStatus() {}

A RolesGuard that reads the @Roles metadata after JwtAuthGuard authenticatesThe @Roles decorator alone, which rejects non-admins at runtimeThe JwtAuthGuard, which also compares the required roleA ValidationPipe that checks the role against the DTO

12. Why is this insecure for the challenge?

Syntaxadvanced

if (req.body.role === 'admin') return this.svc.removeAll();

The check runs before JwtAuthGuard populates the userThe client controls body.role; authorization must use the authenticated user roleThe comparison is case-sensitive, so Admin slips throughbody.role is validated by the pipe but never sanitized

13. Why must JwtAuthGuard be registered before RolesGuard?

Practicalintermediate

providers: [
  { provide: APP_GUARD, useClass: JwtAuthGuard },
  { provide: APP_GUARD, useClass: RolesGuard },
]

APP_GUARD runs providers in reverse registration orderJwtAuthGuard also reads the @Roles metadata for RolesGuardGuards registered later are skipped when the first passesRolesGuard needs request.user, which JwtAuthGuard attaches first

14. A member (authenticated) calls an @Roles(admin) route. What status?

Logicadvanced

// member calls a @Roles('admin') route

401 Unauthorized — the token lacks the admin scope200 OK — the guard logs a warning but allows it403 Forbidden — authenticated but not authorized404 Not Found — the route hides itself from non-admins

15. Does hiding this button secure the delete?

Conceptintermediate

{isAdmin && <button onClick={del}>Delete</button>}

No — an attacker can call the API directly, so the server must enforce itYes — the delete handler is never imported without the buttonYes — the API route is only registered when isAdmin is trueYes — CORS blocks requests that did not come from the UI

Checking your session…