How do I test permissions and role-based access in APIs?

Testing permissions and role-based access in APIs is about verifying who can do what under different authentication and authorization rules.

1) Define the access matrix first

List:

• Roles: e.g. guest, user, manager, admin
• Resources: e.g. /users, /orders/{id}, /reports
• Actions: GET, POST, PUT, DELETE
• Expected access: allowed or denied

Example:

Role	GET /orders	POST /orders	DELETE /orders/{id}
user	yes	yes	no
manager	yes	yes	yes
admin	yes	yes	yes

This becomes your test plan.

---

2) Test both positive and negative cases

For each endpoint, verify:

Positive tests

• Authorized user can access permitted endpoints.
• Response is correct: usually 200, 201, 204, etc.

Negative tests

• Unauthorized user gets blocked.
• Expected status is usually:
  • 401 Unauthorized for missing/invalid authentication
  • 403 Forbidden for valid authentication but insufficient permission

Examples:

• No token → 401
• Valid user token trying admin-only endpoint → 403
• Expired token → 401

---

3) Test by role, not just by username

Create test accounts for each role:

• one regular user
• one privileged user
• one admin
• optionally a disabled/suspended user

Then run the same API call under each identity and compare results.

---

4) Test object-level authorization

This is often missed.

Example:

• User A should not be able to access User B’s order even if both are “user” role.

Test:

• GET /orders/{id} where {id} belongs to another user
• expected: 403 or 404 depending on your security design

This checks ownership-based access, not just role-based access.

---

5) Test edge cases

Include:

• Missing token
• Malformed token
• Expired token
• Revoked token
• Disabled account
• Role changes after login
• Requests with wrong tenant/org ID in multi-tenant systems
• Attempting actions through alternate endpoints or methods

Example:

• A user might be blocked from DELETE /orders/1 but could try PATCH /orders/1 to set status=deleted.

---

6) Verify the server enforces access, not the UI

Even if the frontend hides buttons, API tests should confirm:

• direct API calls are blocked
• authorization is checked on every endpoint
• hidden endpoints aren’t accessible by guessing URLs

---

7) Automate the tests

Use:

• Postman/Newman
• pytest + requests
• JUnit + REST-assured
• SuperTest
• Cypress/API tests
• Karate

Structure tests around:

• authentication setup
• role-specific tokens
• endpoint access assertions

---

8) Example test cases

Example: /admin/reports

• No token → 401
• Regular user token → 403
• Admin token → 200

Example: /orders/{id}

• Owner token → 200
• Other user token → 403 or 404
• Admin token → 200

---

9) What to assert besides status codes

Check:

• response body doesn’t leak sensitive data
• no extra fields returned to low-privilege users
• error messages don’t reveal too much
• audit logs record denied attempts
• rate limits or lockouts work if relevant

---

10) Common mistakes

• Testing only happy paths
• Forgetting object-level permissions
• Not testing expired/revoked tokens
• Assuming frontend restrictions are enough
• Reusing the same test user for all roles
• Not covering multi-tenant boundaries

---

Simple checklist

For each endpoint:

• No token → denied
• Invalid token → denied
• Correct role → allowed
• Wrong role → denied
• Wrong object ownership → denied
• Expired/revoked token → denied
• Sensitive data not leaked

If you want, I can also give you:

1. a sample test matrix,
2. Postman test examples, or
3. pytest/REST-assured code for authorization testing.