mediumMultiple Choice
SSCP Practice Question: A software development team is implementing input…
A software development team is implementing input validation for a web application that accepts user email addresses. Which approach BEST prevents email injection attacks?
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
✓
Whitelist allowed characters: alphanumeric, @, ., -, _
Whitelisting allowed characters (alphanumeric, @, ., -, _) restricts input to safe characters, effectively preventing injection of special characters used in email injection attacks. Option B is incorrect because blacklisting known malicious patterns is easily bypassed by attackers using novel patterns. Option C is incorrect because setting a maximum email length does not prevent injection of malicious characters within that length. Option D is incorrect because client-side validation alone can be bypassed by disabling JavaScript or intercepting requests, so server-side validation is essential.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Whitelist allowed characters: alphanumeric, @, ., -, _
Why this is correct
Whitelisting permitted characters (alphanumeric, @, ., -, _) rejects CRLF sequences and additional headers, the mechanism behind email injection. This input validation directly satisfies the stem's requirement to prevent injection through the email address field, rather than merely filtering known malicious patterns.
- ✗
Blacklist known malicious email patterns
Why it's wrong here
Blacklisting known patterns only blocks previously observed payloads, so novel or encoded injection sequences bypass it; allowlisting a strict email format rejects injected headers outright. It tempts because blocklists are quick to deploy for known attack signatures, yet they cannot enumerate the full grammar of valid email addresses.
- ✗
Set maximum email length to 100 characters
Why it's wrong here
A 100-character limit constrains length only; injected newline or header characters within that limit still pass through and alter mail headers. It tempts because length caps are simple and mitigate buffer issues, but they do not validate the character set or structure of an email address.
- ✗
Rely on client-side JavaScript validation only
Why it's wrong here
Client-side JavaScript runs in the browser and can be disabled or bypassed entirely, so malicious input reaches the server unfiltered. It tempts because it gives immediate user feedback and reduces server load, but server-side validation is required whenever input crosses a trust boundary.
Go deeper
Related to this question
About these practice questions
This SSCP question is part of Courseiva's 971-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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SSCP 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 SSCP exam.