Cyber Security Quiz: Idor And Mitigations
10 questions · exam conditions
0:00
Idor And MitigationsQuestion 1 of 10

A multi-tenant API exposes GET /organizations/{orgId}/projects/{projectId}. It confirms that the authenticated user belongs to orgId, then retrieves the project using only projectId. Project identifiers are globally unique. An attacker supplies the identifier of an organization they belong to together with a project identifier from another organization.

Which authorization change best prevents this attack?

Verify that projectId belongs to orgId and that the current user is authorized for that project before returning it.
Verify membership in orgId and then encode projectId so that identifiers from other organizations have a different format.
Verify that projectId is globally unique and reject requests containing an identifier already used by another organization.
Verify the current user's organization only at login and trust the nested URL to preserve that tenant context.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Idor And Mitigations

Practice Idor And Mitigations in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Idor And Mitigations, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A multi-tenant API exposes GET /organizations/{orgId}/projects/{projectId}. It confirms that the authenticated user belongs to orgId, then retrieves the project using only projectId. Project identifiers are globally unique. An attacker supplies the identifier of an organization they belong to together with a project identifier from another organization.

Which authorization change best prevents this attack?

  1. Verify that projectId belongs to orgId and that the current user is authorized for that project before returning it. (correct answer)
  2. Verify membership in orgId and then encode projectId so that identifiers from other organizations have a different format.
  3. Verify that projectId is globally unique and reject requests containing an identifier already used by another organization.
  4. Verify the current user's organization only at login and trust the nested URL to preserve that tenant context.
Explanation: This question tests your understanding of Broken Object-Level Authorization (BOLA), one of the most critical API vulnerabilities. The core principle: every data retrieval must verify both ownership and access rights, not just one or the other. The attack described is a classic BOLA exploit. The API checks that the user belongs to orgId, but then fetches a project using projectId alone — without confirming that project actually belongs to that organization. An attacker can freely swap in any projectId they discover, crossing tenant boundaries while appearing legitimate in the org check. A is correct because it closes the gap entirely. By verifying that projectId belongs to orgId and that the user is authorized for that specific project, the API enforces a complete authorization chain. The relationship between the two URL parameters is validated, not assumed. B is wrong because encoding or reformatting identifiers is security through obscurity. A determined attacker can still observe valid identifiers from their own organization, probe patterns, or intercept traffic. Format differences don't enforce access boundaries. C is wrong because global uniqueness is already stated in the scenario — it doesn't prevent cross-tenant access. Rejecting duplicate identifiers addresses a non-existent problem and doesn't fix the actual authorization flaw. D is wrong because deferring authorization checks to login time and trusting URL structure is exactly the vulnerable pattern being described. Tenant context must be re-validated on every request, not assumed from session state. When you see hierarchical API endpoints like /parent/{id}/child/{id}, always ask: does the API verify that the child actually belongs to that parent? That's your BOLA red flag.

Question 2

A case-management application allows case owners, assigned investigators, and designated auditors to view a case. A proposed fix for an IDOR issue adds the condition case.owner_id == current_user.id to every case endpoint.

What is the most appropriate evaluation of this proposed mitigation?

  1. It is sufficient because a secure IDOR mitigation must always restrict each object to exactly one authenticated owner.
  2. It is insufficient because authorization must be removed from endpoints and performed only by the user interface.
  3. It may block legitimate access; endpoints should evaluate the case's server-side access policy for the current user and requested action. (correct answer)
  4. It may expose identifiers; endpoints should hash the case owner's identifier before comparing it with the current user.
Explanation: When you encounter IDOR (Insecure Direct Object Reference) questions, focus on whether the proposed fix correctly implements authorization — not just authentication. IDOR vulnerabilities occur when an application exposes object references without verifying whether the current user is permitted to perform the requested action on that object. The proposed fix (case.owner_id == current_user.id) only allows the case owner through. But the passage explicitly states that investigators and auditors also have legitimate access. By hardcoding a single ownership check, the fix breaks valid workflows — an auditor trying to review a case would be denied access, even though that's exactly what auditors are supposed to do. The correct approach, reflected in C, is to evaluate a server-side access policy that accounts for the user's role, their relationship to the case, and the specific action being requested (view, edit, close, etc.). A is wrong because secure IDOR mitigation does not require restricting access to a single owner. Multi-role access is legitimate and common — the mitigation must reflect the full access policy, not oversimplify it. B is a dangerous misconception: moving authorization logic to the UI leaves the server-side endpoints completely unprotected, since UI controls can be bypassed trivially. Authorization must live server-side. D confuses the problem entirely — hashing the owner ID doesn't address whether the current user is authorized; it just obscures an identifier without solving the access-control flaw. As a study tip, remember that IDOR mitigations must enforce access control server-side based on role and relationship, not just identity matching — watch for answers that oversimplify to a single-user ownership check.

Question 3

A multi-tenant service receives GET /records/{id} with an X-Tenant-ID header. Its database query filters by both the record identifier and the header value. Any authenticated user can modify the header. The application does not compare the header with tenant membership stored in the user's server-validated session.

Which revision most effectively closes the authorization gap?

  1. Require both the record identifier and the tenant header to be globally unique across all tenants before allowing the lookup to proceed.
  2. Continue trusting the tenant header but reject values containing characters that are not letters, digits, or hyphens to block malformed input.
  3. Encrypt the tenant header value in browser-side code before sending it, then decrypt it server-side before using it in the database query.
  4. Derive allowed tenant context from trusted session claims or server-side membership data, then scope the record lookup to that context. (correct answer)
Explanation: When you see a question about multi-tenant authorization, your mental anchor should be: who controls the data that gates access? If the user controls it, it cannot be trusted for authorization decisions. That principle cuts straight to the heart of this scenario. The authorization gap here is a classic Broken Object Level Authorization (BOLA) flaw — the application uses a client-supplied header (X-Tenant-ID) to scope database queries instead of deriving tenant context from something the server already verified. Answer D closes this gap directly: by pulling tenant membership from the validated session or authoritative server-side data, the server — not the client — determines which tenant a user belongs to, and the record lookup is scoped accordingly. An attacker who modifies the header gains nothing, because the header is simply ignored for authorization. Answer A misunderstands the problem entirely. Enforcing global uniqueness of identifiers is a data-integrity concern, not an authorization fix — a user could still query records belonging to a different tenant. Answer B is an input-validation measure that sanitizes the header's format, but a well-formed X-Tenant-ID value belonging to a different tenant is just as dangerous as a malformed one; filtering characters does nothing to prevent tenant hopping. Answer C introduces encryption, which provides confidentiality in transit but zero authorization enforcement — once decrypted server-side, the untrusted client-supplied value is still used as the trust boundary, leaving the flaw intact. A reliable study tip: whenever a question involves a value the client can freely set or modify, any answer that validates, sanitizes, or encrypts that value without replacing it with server-authoritative data is a distractor. True authorization fixes always move trust to the server side.

Question 4

An application lets customers generate account exports. POST /exports verifies that the authenticated customer owns the requested account and returns a random export job identifier. Later, GET /exports/{jobId} verifies only that the requester is authenticated before returning the completed file. The job identifiers are long and unpredictable.

Which change most directly addresses the remaining IDOR risk?

  1. Require GET /exports/{jobId} to verify that the job is authorized for the authenticated customer before returning it. (correct answer)
  2. Increase the job identifier length so that another authenticated customer cannot feasibly enumerate active export jobs.
  3. Require a fresh anti-CSRF token on POST /exports so that unauthorized users cannot initiate export jobs.
  4. Remove job identifiers from browser history so that customers are less likely to disclose completed export links.
Explanation: When you see a question involving access control on individual resources, you should immediately think about Insecure Direct Object Reference (IDOR) — a vulnerability where an attacker accesses resources belonging to another user simply by referencing their identifier. The key diagnostic question is: at every endpoint that returns sensitive data, does the server verify ownership, not just authentication? Here, POST /exports correctly checks ownership, but GET /exports/{jobId} only checks that the requester is logged in — any authenticated customer could retrieve another customer's export file if they somehow obtained the job ID. That's the IDOR gap. Answer A closes it directly by adding an authorization check at the retrieval endpoint, ensuring the authenticated user actually owns that specific job before the file is returned. This is the principle of enforcing object-level authorization at every sensitive operation, not just creation. B is a common misconception — making identifiers long and random (security through obscurity) reduces guessability but doesn't eliminate the vulnerability. If a job ID is ever leaked via logs, referrer headers, or shared links, the flaw remains fully exploitable. Obscurity is not authorization. C addresses CSRF, which is a completely different attack class involving forged requests from another origin. CSRF protection on POST /exports has no bearing on whether an authenticated attacker can retrieve someone else's export via GET. D is a client-side mitigation that does nothing to enforce server-side access control — it only slightly reduces accidental disclosure. Your study takeaway: authentication ≠ authorization. IDOR vulnerabilities exist when a server confirms who you are but not whether you're allowed to access this specific object. Always look for per-object ownership checks.

Question 5

An origin server correctly verifies ownership before returning /statements/{statementId}. A newly added CDN caches successful responses using only the URL path as the cache key. It does not vary the cache by authenticated user or session. After one customer requests a statement, another authenticated customer requests the same path and receives the cached response without the origin being contacted.

Which remediation most directly preserves object-level authorization in this architecture?

  1. Configure private or nonshared caching for these responses, or ensure each cache hit is safely partitioned by the authorized user context. (correct answer)
  2. Keep shared caching enabled but replace statement identifiers with UUIDs so customers cannot intentionally enumerate cached paths.
  3. Move the origin's ownership check to the statement creation workflow so authorization occurs before any response can be cached.
  4. Add an anti-CSRF token to statement links so the CDN can distinguish legitimate reads from cross-site requests.
Explanation: When a CDN caches responses without considering who is authorized to see them, it effectively strips away object-level authorization — a classic Broken Object Level Authorization (BOLA) vulnerability introduced at the infrastructure layer rather than the application layer. Questions like this test whether you understand that authorization must survive every layer of the architecture, not just the origin server. The core problem here is cache partitioning: the CDN stores one customer's statement response and serves it to any subsequent requester hitting the same URL. Answer A directly fixes this by either marking responses as Cache-Control: private (preventing CDN storage entirely) or by partitioning cache entries per authenticated user context — ensuring the authorization boundary is maintained regardless of caching behavior. This is the most direct remediation because it addresses the exact mechanism causing the leak. B is a common distractor that confuses obscurity with security. UUIDs make enumeration harder, but if an attacker already knows or can observe a valid statement URL, the CDN still serves them the cached response without authorization checks. Guessability and authorization are separate problems. C sounds clever but is logically flawed. Moving the ownership check to creation time doesn't help when the vulnerability occurs at retrieval time. Authorization must be enforced when the resource is accessed, not just when it's created. D conflates CSRF protection with authorization. Anti-CSRF tokens prevent cross-site request forgery; they have no bearing on whether an authenticated-but-unauthorized user retrieves a cached document through a normal request. Your takeaway: when caching is introduced into an architecture, always ask "is the cache key scoped to the authorized user?" If not, caching can silently break object-level access control.

Question 6

A storage platform queues deletion requests. The web tier verifies that the requester currently has permission to delete /folders/{folderId}, then places only folderId in a queue. Before the worker processes the job, the folder is transferred to another department and the requester's access is revoked. The worker deletes the folder without performing another authorization check.

Which approach best addresses the object-authorization risk while preserving queued processing?

  1. Require an anti-CSRF token when the worker reads the queue message so delayed deletion requests cannot be forged.
  2. Have the worker accept the queued folder identifier because the web tier authenticated the requester when the job was submitted.
  3. Replace the folder identifier with a random queue identifier so ownership changes cannot be inferred by the requester.
  4. Have the worker validate a trustworthy authorization context or approved immutable grant against the folder before performing the deletion. (correct answer)
Explanation: When authorization is checked at one point in time but an action executes later, you're dealing with a Time-of-Check to Time-of-Use (TOCTOU) vulnerability. In queued architectures, this gap between "when the request was validated" and "when the work actually runs" is exactly where attackers—or simply changed circumstances—can undermine access controls. The correct answer is D because it closes that temporal gap directly. Having the worker re-validate authorization at execution time ensures that any permission changes occurring between job submission and job processing are respected. This could mean re-querying the current ACL, checking a short-lived signed grant, or verifying an immutable authorization token that was cryptographically bound to the original permission state. Either way, the worker never blindly trusts stale context. A is a red herring. CSRF tokens protect against cross-site request forgery on synchronous web requests—they don't address whether a requester still has permission to delete a resource when a background worker eventually processes it. This conflates two entirely different vulnerability classes. B describes the exact flaw the question is warning against. Trusting that "the web tier already checked" is precisely the TOCTOU mistake. Authorization at submission time says nothing about authorization at execution time, especially when ownership can transfer in between. C obscures the folder identifier to prevent inference of ownership relationships, which is a privacy/enumeration concern. It does nothing to stop an unauthorized deletion from proceeding—the worker still lacks a re-authorization step. When you see queued or asynchronous processing in a security scenario, immediately ask: "Is authorization checked at execution time, or only at submission time?" That question will guide you straight to the right answer.

Question 7

A document service replaces sequential document numbers with UUIDs. During a support session, a user receives another customer's document UUID in an error message. Substituting that UUID into GET /documents/{uuid} returns the other customer's document because the endpoint checks only whether the requester is logged in.

Which assessment of the design is most accurate?

  1. The UUID design prevents IDOR because direct object references are insecure only when identifiers can be enumerated.
  2. The endpoint remains vulnerable because identifier unpredictability does not establish authorization to access the referenced document. (correct answer)
  3. The endpoint is primarily vulnerable to injection because the server accepts a user-controlled UUID in the request path.
  4. The endpoint is secure if UUID generation uses enough entropy, because disclosure through another component is outside its trust boundary.
Explanation: When you see a question involving access control and object identifiers, the core concept to test is what actually enforces authorization — not what makes guessing harder. These are two completely different security properties, and conflating them is exactly the trap this question sets. The scenario describes a classic Insecure Direct Object Reference (IDOR) vulnerability. The endpoint checks only authentication (is the user logged in?) but never authorization (does this user own this document?). This is why B is correct — unpredictability is a property of the identifier's secrecy, not a substitute for access control logic. Once a UUID leaks through any channel (an error message, a log, a shared link), an attacker can use it freely if the server never verifies ownership. A is wrong because it frames enumeration as the only threat model for IDOR. In reality, IDOR exists whenever a user can manipulate a reference to access an unauthorized object — whether that reference was guessed, leaked, or stolen. Enumerability affects discoverability, not the underlying vulnerability class. C misidentifies the vulnerability category. Accepting user-controlled input in a URL path is normal REST behavior, not injection. Injection requires that user input alters the structure or interpretation of a command (SQL, shell, etc.) — that's not what's happening here. D is the most dangerous distractor. It argues that a leak from a separate component is outside the endpoint's responsibility. But defense-in-depth requires the endpoint to enforce authorization regardless of how an identifier was obtained. Study tip: When evaluating access control, always ask two separate questions: Can the user prove who they are? (authentication) and Are they allowed to touch this resource? (authorization). UUID secrecy can support the latter but never replace it.

Question 8

A medical portal provides links such as /reports/{reportId}?sig={signature}. The signature proves that the report identifier was generated by the portal and expires after one hour, but it is not bound to a user. The requirement states that reports must remain accessible only to the authenticated patient who owns them. Links can appear in browser synchronization records and proxy logs.

Which design best satisfies the stated requirement?

  1. Retain the signature and return the report to any requester who presents it before its expiration time.
  2. Shorten the signature lifetime and rely on the reduced opportunity for another user to reuse a leaked link.
  3. After validating the signature, verify server-side that the authenticated patient is authorized for the referenced report. (correct answer)
  4. Encrypt reportId within the link so that recipients cannot determine which database record it references.
Explanation: When you see an access control question involving signed URLs or tokens, ask yourself: what does the credential actually prove? A signature proves authenticity — that the link was legitimately generated — but it says nothing about who is allowed to use it. These are two separate security concerns, and conflating them is the core trap this question is testing. Option C is correct because it enforces authorization as a distinct, server-side check. After confirming the signature is valid, the server also confirms that the currently authenticated user is the owner of that specific report. This directly satisfies the stated requirement: reports are accessible only to the patient who owns them, regardless of how the link was obtained. Option A fails because it grants access based solely on possessing a valid signature. Since the signature isn't bound to a user, anyone who intercepts the link from browser sync records or proxy logs can freely access the report — exactly the threat the requirement is trying to prevent. Option B reduces the window of exposure but doesn't close the vulnerability. A shorter lifetime still allows unauthorized access if the link is intercepted quickly, and it offers zero protection against misuse within that window. Reducing risk is not the same as satisfying a security requirement. Option D addresses confidentiality of the report identifier, not authorization. Even if an attacker can't decode which record a link references, they can still present the encrypted link and receive the report if no ownership check is performed. Your takeaway: when a requirement says "only the owner should access this," look for server-side authorization checks tied to the authenticated user's identity — not just token validation, expiration, or obscurity.

Question 9

A banking application uses POST /payees/{payeeId}/delete. The request requires a valid session cookie and an anti-CSRF token. The server deletes the referenced payee without checking which customer owns it. A customer can submit another customer's payee identifier using their own valid token.

Why does the anti-CSRF control not prevent this IDOR attack?

  1. The token confirms that the request originated in an approved browser flow, but it does not authorize the customer for the referenced payee. (correct answer)
  2. The token protects only read operations, while object authorization is required exclusively for state-changing operations such as deletion.
  3. The token is ineffective because CSRF defenses work only when resource identifiers are sequential rather than randomly generated.
  4. The token authenticates the payee instead of the customer, so the application must replace it with HTTP basic authentication.
Explanation: When you see a question mixing two different vulnerability types, pause and ask yourself: what does each control actually protect? Here, the question is testing whether you can distinguish between CSRF protection (which validates request origin) and authorization (which validates resource ownership). An anti-CSRF token answers one question: "Did this request legitimately originate from our application's own UI flow, submitted by whoever holds this session?" It does not answer: "Does this authenticated user have the right to act on this specific object?" That's why A is correct — the token successfully confirms the request came from a real, in-session browser flow, but it says nothing about whether this customer owns payee #4892. The attacker simply uses their own valid session and token while swapping in a victim's payee ID. Both checks pass; the missing check is ownership. B is wrong because it invents a false rule — anti-CSRF tokens absolutely apply to state-changing operations; that's their primary purpose. The flaw isn't about which operations the token covers. C is wrong because CSRF defense effectiveness has nothing to do with whether resource identifiers are sequential or random. You're conflating CSRF with IDOR enumeration risk, which is a separate concern. D is nonsensical — the token doesn't authenticate the payee at all, and replacing CSRF tokens with HTTP Basic Authentication would solve neither the CSRF problem nor the IDOR problem. Study tip: On security exams, remember that authentication, CSRF protection, and object-level authorization are three separate layers. A question showing that one layer is satisfied while another is bypassed is almost always testing whether you understand their distinct, non-overlapping responsibilities.

Question 10

A GraphQL API exposes node(id: ID!), which can return invoices, projects, or public articles. The top-level resolver verifies that the requester is authenticated. Type-specific resolvers then load objects by decoded database identifier. Only the invoice list query applies an ownership filter.

Which change provides the most reliable mitigation for invoice IDOR through node?

  1. Keep the list query's ownership filter and disable invoice identifier display in the application's normal user interface.
  2. Apply invoice-specific authorization whenever an invoice object is resolved, regardless of which GraphQL query path reached it. (correct answer)
  3. Require authentication in the top-level resolver and treat that successful check as authorization for every supported object type.
  4. Base64-encode invoice identifiers again before returning them so clients cannot derive the underlying database identifier.
Explanation: When you see a question about API authorization and IDOR (Insecure Direct Object Reference), the core principle to anchor on is this: authorization must be enforced at the object level, not just at the entry point. The fact that GraphQL allows multiple query paths to reach the same underlying object makes this especially critical. The node interface is a perfect storm for IDOR because it provides a generic, unified access point. Even if the invoice list query enforces ownership, an attacker can bypass that filter entirely by calling node(id: "$invoice_123$") directly. The fix, which is what B describes, is to enforce invoice ownership checks inside the invoice type resolver itself — so no matter how a client reaches an invoice object (list query, node query, or any future query), authorization fires every time. This is called object-level authorization, and it's the only reliable defense. A is a UI-level control, not a server-side control. Hiding identifiers in the interface doesn't prevent an attacker from observing them through traffic analysis or from guessing them. Security through obscurity is not authorization. C describes the exact vulnerability in the passage — confusing authentication (who are you?) with authorization (are you allowed to access this specific invoice?). Confirming a user is logged in doesn't mean they own every object they request. D is another obscurity measure. Base64 is encoding, not encryption. Identifiers remain guessable or observable, and encoding them provides zero access control. For exam questions about IDOR, always ask: where exactly is the ownership check enforced? If the answer is anywhere other than the object resolver itself, the protection can be bypassed.