RBAC

API Securityintermediate

// Definition

Role-Based Access Control — a permission model where access rights are assigned to roles, and users inherit permissions by belonging to one or more roles. A `viewer` role can read resources; an `admin` role can create, update, and delete. In API testing, RBAC tests verify that each role can reach only the endpoints it should: a viewer calling `DELETE /content` should get a 403, not a 200. Broken access control at the object and function level is consistently in the OWASP API Security Top 10.

// Why it matters

RBAC assigns permissions to roles and users inherit them by role. QA's job is the negative matrix: for every role × every protected action, confirm the forbidden combinations actually return 403 — the positive cases usually get tested; the denials are where escalation bugs hide.

// How to test

// Matrix-test denials: a viewer must not reach admin actions
const forbidden = [
  { role: 'viewer', method: 'DELETE', url: '/api/users/9' },
  { role: 'editor', method: 'POST',   url: '/api/billing/refund' },
]
forbidden.forEach(({ role, method, url }) =>
  cy.request({ method, url, headers: tokenFor(role), failOnStatusCode: false })
    .its('status').should('eq', 403)
)

// Common mistakes

  • Hiding a button in the UI but leaving the API endpoint open
  • Testing what each role can do, never what it can't
  • Role checks at the route but not on nested/bulk operations

// Related terms