Role-Based Access Control

Frontend-only RBAC can be bypassed trivially. Compare against server-validated token-based enforcement.

Try this:Select 'guest' role, then try the 'Delete Record' action

Select Role to Simulate

Frontend-Only Check
Role check in JavaScript only β€” trivially bypassable

// In browser console:

window.__role = "admin"

// Access granted instantly

πŸ“– Read Data
✏️ Write Data
πŸ—‘οΈ Delete Record
πŸ‘₯ Manage Users
Server-Enforced Check
Role decoded from signed JWT on the server

// Server decodes your JWT:

const role = verify(token, SECRET)

// Client cannot forge this

πŸ“– Read Data
✏️ Write Data
πŸ—‘οΈ Delete Record
πŸ‘₯ Manage Users

Test Actions

Vulnerable
What's happening

RBAC restricts what actions a user can perform based on their role. A frontend-only check shows/hides UI buttons based on the role stored in JavaScript β€” but this is just cosmetic.

Why it's vulnerable

JavaScript runs in the browser. Anyone can open DevTools, change a variable from 'guest' to 'admin', and bypass any client-side check. The frontend is an untrusted environment.

How it's fixed

Always enforce permissions on the server. Use a signed JWT β€” the server decodes the role from the token and checks permissions before executing any action. The client cannot forge a server-signed token.

Real-world context

Many early SPA applications put admin routes behind a simple JS check like if (user.role === 'admin'). Attackers bypassed this by editing localStorage or JS variables directly in the console.

Security Log(0)

Monitoring runtime activity… waiting for events

Stream will begin shortly