Cloud Application Security →hardMultiple Choice

CCSP Cloud Application Security Practice Question

A software company develops a mobile application that communicates with a cloud backend using REST APIs. The application uses OAuth 2.0 with the authorization code grant and PKCE for authentication. After a security audit, the team identifies that the backend API accepts both a client secret (from the authorization code grant) and a PKCE code verifier. The security team wants to remove unnecessary attack surface. Which change should be made?

⚠ Common exam trap

ISC2 often tests the misconception that removing the client_secret weakens security, when in fact for public clients (mobile apps, SPAs) PKCE makes the secret unnecessary and its removal reduces attack surface; candidates may incorrectly think keeping the secret adds a layer of defense, but it actually introduces a static credential that can be stolen.

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

✓

Remove the client_secret parameter from the token endpoint and rely solely on PKCE

PKCE (Proof Key for Code Exchange, RFC 7636) was specifically designed to secure the authorization code grant for public clients like mobile apps, where a client secret cannot be reliably kept confidential. By removing the client_secret parameter and relying solely on PKCE, the team eliminates an unnecessary attack surface—since the secret is effectively a static credential that can be extracted from the app binary—while maintaining strong protection against authorization code interception attacks. The backend should enforce PKCE verification using the code_challenge and code_verifier, making the client_secret redundant for public clients.

Answer analysis

Option-by-option breakdown

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

✗
Switch to the implicit grant (response_type=token) to avoid client secrets
Why it's wrong here
The implicit grant returns tokens directly in the redirect URI fragment and cannot use PKCE, so it removes the client secret while adding token-exposure risk. Implicit suits browser-only JavaScript clients lacking a backend token exchange, not a mobile app that already supports the authorization code flow.
✗
Keep both mechanisms but use short-lived tokens to reduce risk
Why it's wrong here
Short-lived tokens limit the window of misuse but leave both credential mechanisms accepted, so the unnecessary attack surface the audit flagged remains. Token lifetime reduction addresses replay exposure, and would be the right control where credential removal is not feasible.
✓
Remove the client_secret parameter from the token endpoint and rely solely on PKCE
Why this is correct
PKCE binds the authorization code to the client via a dynamically generated code verifier, so a public mobile client cannot protect a static secret. Removing client_secret eliminates a credential that could be extracted from the app bundle, satisfying the goal of reducing unnecessary attack surface.
✗
Require a stronger client secret (e.g., 256-bit) and store it in the app's encrypted storage
Why it's wrong here
A longer client secret stored on the device is still extractable from the mobile app, and the backend continues accepting two credential types. Strengthening secret length suits confidential server-side clients that can protect credentials, not public mobile clients where PKCE replaces the secret.

Go deeper

CCSP Cloud Application Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question