Comparison questionMedium~7 minAPI Security & Auth Essentials / 7 of 20

Interview question

How would you model roles and permissions for an API without creating a messy role explosion?

Compare roles, permissions, and capabilities

Explains how roles group permissions while API policies enforce specific capabilities and resource rules.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would use roles as coarse user-facing groups and permissions or capabilities as the specific actions the API checks. For example, Editor can include content read and update, while Admin can include user management. The endpoint checks the capability it needs, not a broad role name everywhere. That avoids adding a new role for every tiny workflow difference.

Full answer below

Practice focus

Roles, permissions, capabilities, policy checks, role explosion, least privilege, and resource-level authorization.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Role modeling is a common source of long-term security and product pain. The useful answer keeps roles human-friendly while enforcing precise permissions in code.
I would use roles as coarse user-facing groups and permissions or capabilities as the specific actions the API checks. For example, Editor can include content read and update, while Admin can include user management. The endpoint checks the capability it needs, not a broad role name everywhere. That avoids adding a new role for every tiny workflow difference.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would keep the permission list small and tied to real product actions: content publish, user manage, import run, suggestion review, and so on. Roles become assignments of those capabilities. Some checks still need resource context, such as own record versus any record, tenant membership, or content status. A capability can say the user may attempt an action; the resource policy decides whether this specific target is allowed.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I keep capability definitions centralized, deny by default, and version role-to-capability assignments like any other security contract. Admin screens show effective access in human terms, while API tests cover both allowed and denied paths for each sensitive action. Resource policies still enforce ownership, tenant, and workflow state after the capability check. Changes need a plan for stale token claims, cached permission sets, and migration from old role names so a rollout cannot accidentally broaden access.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Checking only broad Admin roles for unrelated actions.
Creating many one-off roles instead of reusable capabilities.
Ignoring resource ownership after a capability check passes.
Letting frontend navigation decide access.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

No distinction between role and permission.
No least-privilege story.
No tests for denied paths.
Cannot explain how capabilities appear in UI and API together.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is a role useful?
When is a resource policy still needed?
How would you show effective permissions to admins?

Continue the section

Next in API Security & Auth Essentials: IDOR

Step 8 of 20

Prevent IDOR with resource ownership checks

Opening drill

Comparison questionMedium~7 minAPI Security & Auth Essentials / 7 of 20

Interview question

How would you model roles and permissions for an API without creating a messy role explosion?

Compare roles, permissions, and capabilities

Explains how roles group permissions while API policies enforce specific capabilities and resource rules.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Roles, permissions, capabilities, policy checks, role explosion, least privilege, and resource-level authorization.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Role modeling is a common source of long-term security and product pain. The useful answer keeps roles human-friendly while enforcing precise permissions in code.
I would use roles as coarse user-facing groups and permissions or capabilities as the specific actions the API checks. For example, Editor can include content read and update, while Admin can include user management. The endpoint checks the capability it needs, not a broad role name everywhere. That avoids adding a new role for every tiny workflow difference.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would keep the permission list small and tied to real product actions: content publish, user manage, import run, suggestion review, and so on. Roles become assignments of those capabilities. Some checks still need resource context, such as own record versus any record, tenant membership, or content status. A capability can say the user may attempt an action; the resource policy decides whether this specific target is allowed.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I keep capability definitions centralized, deny by default, and version role-to-capability assignments like any other security contract. Admin screens show effective access in human terms, while API tests cover both allowed and denied paths for each sensitive action. Resource policies still enforce ownership, tenant, and workflow state after the capability check. Changes need a plan for stale token claims, cached permission sets, and migration from old role names so a rollout cannot accidentally broaden access.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Checking only broad Admin roles for unrelated actions.
Creating many one-off roles instead of reusable capabilities.
Ignoring resource ownership after a capability check passes.
Letting frontend navigation decide access.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

No distinction between role and permission.
No least-privilege story.
No tests for denied paths.
Cannot explain how capabilities appear in UI and API together.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is a role useful?
When is a resource policy still needed?
How would you show effective permissions to admins?

Continue the section

Next in API Security & Auth Essentials: IDOR

Step 8 of 20

Prevent IDOR with resource ownership checks

How would you model roles and permissions for an API without creating a messy role explosion?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you model roles and permissions for an API without creating a messy role explosion?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section