Courseiva

CCSP Cloud Application Security Practice Question

A healthcare organization runs a multi-tenant SaaS application on a public cloud. Each tenant's data is stored in a shared database with a tenant identifier column. A penetration test shows that a crafted API request can return records belonging to another tenant. The application already authenticates users and validates their tenant membership at login. Which control most directly addresses the root cause of this finding?

⚠ Common exam trap

The trap here is treating a cross-tenant data leak as an authentication or network problem when the actual defect is server-side authorization of each data access.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Enforce tenant scoping in the data access layer by deriving the tenant identifier from the authenticated session and applying it to every query, ignoring any tenant value supplied by the client.

The penetration test demonstrates broken object-level authorization, where the API accepts a client-controlled tenant identifier and uses it to scope queries. The durable fix is to derive the tenant from the authenticated session and enforce that scope in the data access layer so client input can never widen it. WAF rules, schema separation, and mutual TLS each add defense in depth but do not correct the authorization flaw that allows cross-tenant reads.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    Enforce tenant scoping in the data access layer by deriving the tenant identifier from the authenticated session and applying it to every query, ignoring any tenant value supplied by the client.

    Why this is correct

    The vulnerability is broken object-level authorization: the API trusts a client-supplied tenant identifier instead of binding queries to the authenticated principal. Deriving the tenant from the validated session and injecting it into every query ensures a user can never read another tenant's rows, regardless of what the request contains. This fixes the root cause at the point where data is retrieved.

  • ✗

    Move each tenant's data into a separate database schema and grant the application role access only to the schema matching the authenticated tenant.

    Why it's wrong here

    Schema isolation reduces blast radius and is a sound architectural improvement, but it does not by itself correct the flawed authorization logic. If the code still builds queries using a client-supplied tenant value, the application could be pointed at another schema through the same broken path. The immediate root cause is the trust boundary in the data access code, not the storage layout.

  • ✗

    Require tenants to authenticate with mutual TLS and bind each client certificate to a tenant identifier that the API validates on every request.

    Why it's wrong here

    Mutual TLS strengthens client authentication but does not change how the application authorizes data access after authentication. A valid certificate for tenant A still permits a request that asks for tenant B's records if the query logic trusts the request parameter. The finding is an authorization defect, and stronger authentication alone leaves it exploitable by any legitimate tenant.

  • ✗

    Add a web application firewall rule that inspects API request bodies for tenant identifier values that differ from the authenticated user's tenant.

    Why it's wrong here

    A WAF signature can catch known patterns but cannot reliably understand application semantics, especially when tenant identifiers are embedded in nested JSON, encoded, or derived server-side. It treats the symptom at the network edge and is trivially bypassed by parameter pollution or alternate encodings. The root cause is missing server-side authorization on each data access, which a WAF does not fix.

About these practice questions

This CCSP question is part of Courseiva's 934-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official ISC2 exam blueprint

This CCSP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CCSP exam.