Concept questionMedium~7 minAPI Security & Auth Essentials / 8 of 20

Interview question

What is an IDOR vulnerability, and how would you prevent it in an API?

Prevent IDOR with resource ownership checks

Explains insecure direct object reference risks and how APIs enforce ownership, tenant scope, and authorization per resource.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

An IDOR happens when the API accepts a resource id and returns or changes that resource without checking whether the caller is allowed to access it. The fix is not just using GUIDs. The API must check ownership, tenant membership, role, or capability against the resource before returning data or applying changes.

Full answer below

Practice focus

Resource ownership, object identifiers, tenant scope, policy checks, query filtering, and safe not-found behavior.

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
IDOR is one of the most practical API security bugs: the caller changes an id and accesses another user's data.
An IDOR happens when the API accepts a resource id and returns or changes that resource without checking whether the caller is allowed to access it. The fix is not just using GUIDs. The API must check ownership, tenant membership, role, or capability against the resource before returning data or applying changes.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would build the check into the data access or policy path so it is hard to forget. For example, queries can filter by both resource id and current tenant or owner. If the resource exists but the user cannot access it, the API may return 404 for privacy-sensitive resources or 403 where revealing existence is acceptable. The decision should be consistent and documented.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I make resource scoping difficult to bypass. Repository queries include the current owner or tenant where practical, policy checks run before side effects, and cache keys include every security boundary that changes visibility. Tests cover guessed identifiers, nested and bulk routes, exports, background jobs, indirect references, and cross-tenant access. Denied probes are logged with safe actor and resource context, but responses do not reveal private existence. Administrative bypasses are explicit capabilities rather than hidden exceptions in generic queries.

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

Assuming GUIDs are enough protection.
Checking ownership in the UI only.
Filtering by id but not tenant or owner.
Forgetting bulk/export endpoints.

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

Details

Cannot explain IDOR with a concrete example.
No server-side ownership check.
No cross-tenant tests.
Leaks private resource existence inconsistently.

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 would you return 404 instead of 403?
How would you test IDOR?
Where can IDOR hide outside normal CRUD endpoints?

Continue the section

Next in API Security & Auth Essentials: Policy Auth

Step 9 of 20

Use ASP.NET Core policies for authorization

Opening drill

Concept questionMedium~7 minAPI Security & Auth Essentials / 8 of 20

Interview question

What is an IDOR vulnerability, and how would you prevent it in an API?

Prevent IDOR with resource ownership checks

Explains insecure direct object reference risks and how APIs enforce ownership, tenant scope, and authorization per resource.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Resource ownership, object identifiers, tenant scope, policy checks, query filtering, and safe not-found behavior.

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
IDOR is one of the most practical API security bugs: the caller changes an id and accesses another user's data.
An IDOR happens when the API accepts a resource id and returns or changes that resource without checking whether the caller is allowed to access it. The fix is not just using GUIDs. The API must check ownership, tenant membership, role, or capability against the resource before returning data or applying changes.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would build the check into the data access or policy path so it is hard to forget. For example, queries can filter by both resource id and current tenant or owner. If the resource exists but the user cannot access it, the API may return 404 for privacy-sensitive resources or 403 where revealing existence is acceptable. The decision should be consistent and documented.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I make resource scoping difficult to bypass. Repository queries include the current owner or tenant where practical, policy checks run before side effects, and cache keys include every security boundary that changes visibility. Tests cover guessed identifiers, nested and bulk routes, exports, background jobs, indirect references, and cross-tenant access. Denied probes are logged with safe actor and resource context, but responses do not reveal private existence. Administrative bypasses are explicit capabilities rather than hidden exceptions in generic queries.

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

Assuming GUIDs are enough protection.
Checking ownership in the UI only.
Filtering by id but not tenant or owner.
Forgetting bulk/export endpoints.

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

Details

Cannot explain IDOR with a concrete example.
No server-side ownership check.
No cross-tenant tests.
Leaks private resource existence inconsistently.

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 would you return 404 instead of 403?
How would you test IDOR?
Where can IDOR hide outside normal CRUD endpoints?

Continue the section

Next in API Security & Auth Essentials: Policy Auth

Step 9 of 20

Use ASP.NET Core policies for authorization

What is an IDOR vulnerability, and how would you prevent it in an API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

What is an IDOR vulnerability, and how would you prevent it in an API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section