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
Implicit grant is less secure and deprecated; PKCE is the modern standard.
- ✗
Keep both mechanisms but use short-lived tokens to reduce risk
Why it's wrong here
Both mechanisms add complexity and risk; PKCE alone suffices.
- ✓
Remove the client_secret parameter from the token endpoint and rely solely on PKCE
Why this is correct
PKCE is designed for public clients without a secret, reducing 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
Encrypted storage on mobile can still be bypassed; secrets are inherently compromised.
Go deeper
Related to this question
About these practice questions
One of 964 original CCSP practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.