Back to API Practice

Security/Auth API trainer

Roles & Permissions API Practice

Practice testing role-based access control, permissions, forbidden actions, admin-only endpoints, tenant isolation, and privilege escalation risks.

How to use this trainer

Choose, send, inspect, write, improve

Safe client-side simulator. No real backend is called and no real data is sent.

  1. 1Choose a preset case
  2. 2Send a simulated request
  3. 3Read the response and QA note
  4. 4Write what you would test
  5. 5Check your coverage

Interactive sandbox

Try the API request

Edit the request body, send a simulated PATCH /api/users/{userId}/role request, and inspect authorization, tenant isolation, and privilege escalation behavior. No real data is sent.

Request

Build the role-change request

PATCH/api/users/{userId}/role
application/json

Test case presets

Choose a case, inspect the fake response, then write what you would test.

Happy path

Auth / permission

Tenant / escalation

Validation / state

Reliability

Response

Fake API result

Send a simulated request to see the HTTP status, JSON response, QA note, and the RBAC/security risks this case should make you mention in your answer.

List admin success, forbidden users, missing/expired tokens, tenant isolation, invalid roles, privilege escalation, self-demotion, stale tokens, audit logs, safe errors, outages, concurrency, and performance.

Tip: a stronger answer usually mixes happy path, negative cases, state changes, data, backend, UX, accessibility, and risk.

How to structure your answer

Happy pathNegative casesData rulesSecurity/API risksUX/performance
API ReferenceEndpoint, request fields, responses, and business rulesExpand

API reference

Roles & Permissions endpoint

Change a user role when the requester has the required permission.

Endpoint

PATCH/api/users/{userId}/role

Purpose

Change user role when the requester has the required permission.

Request fields

  • authToken: string, required in simulator
  • tenantId: string, required
  • targetUserId: string, required
  • newRole: string, required

Supported roles

usermanageradmin

Request body

{
  "targetUserId": "user-456",
  "newRole": "admin"
}

Auth context

{
  "Authorization": "Bearer admin-token",
  "X-Tenant-Id": "tenant-a"
}

Success response

200 OK

{
  "userId": "user-456",
  "role": "admin",
  "updatedBy": "user-123",
  "tenantId": "tenant-a"
}

Errors

  • 400 validation error
  • 401 missing or expired token
  • 403 forbidden or privilege escalation
  • 404 user not found / tenant isolation
  • 409 disabled user or self-demotion conflict
  • 503 audit or permission service unavailable

Security notes

  • Never trust role from client-side UI
  • Server must enforce permissions
  • Tenant isolation must be enforced server-side
  • User should not assign a role higher than their own
  • Role changes should be audit logged
  • Tokens and sensitive auth context must not be logged

Business rules

  • requester must have role:write permission
  • tenant claim must match target user tenant
  • role must be one of user, manager, admin
  • super_admin and hidden permissions are restricted
  • self-demotion can be blocked by last-admin rules
  • audit logging can be required before commit
  • stale tokens should not preserve old access forever
  • concurrent role updates must be consistent

API interview guide

What this Roles & Permissions API practice covers

This scenario trains authorization testing for role changes, permission boundaries, tenant isolation, auditability, and direct API bypass attempts.

Key risks covered

  • - Valid role change by an authorized admin with correct response schema.
  • - Missing role, invalid role, unsupported role, and malformed request body.
  • - Self-escalation, lower-privilege role changes, and direct API access denial.
  • - Tenant or workspace isolation for cross-tenant users and resources.
  • - Audit logs, permission cache refresh, concurrent updates, and safe authorization errors.

Example interview prompt

How would you test an API that changes a user's role inside a tenant or workspace?

Common mistakes

  • - Only testing admin can change role.
  • - Forgetting direct API access, cross-tenant access, and self-escalation.
  • - Not checking audit logs, permission cache, concurrent changes, or denial response shape.