mediumMultiple Select
CISSP Practice Question: Which TWO of the following are mandatory secure…
Which TWO of the following are mandatory secure coding practices to prevent injection attacks? (Select exactly two.)
⚠ Common exam trap
Many exam-takers confuse output encoding (which prevents XSS) with input validation/sanitization (which prevents injection), but the CISSP expects you to recognize that parameterized queries are the definitive defense against SQL injection, while input validation is a broader, mandatory practice for all injection types.
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
✓
Use parameterized queries or prepared statements
Option D is correct because parameterized queries or prepared statements ensure that user-supplied data is treated strictly as data, not executable code, which structurally prevents SQL injection and similar injection flaws by separating the query logic from the input values. Option E is correct because validating and sanitizing all user input enforces allow-list or expected-format checks and strips or neutralizes dangerous characters, reducing the attack surface for injection vectors such as SQL, command, and LDAP injection. Option A is not mandatory for preventing injection itself; output encoding primarily mitigates cross-site scripting (XSS) by rendering data inert in the browser context, which is a different vulnerability class. Option B is incorrect because encrypting sensitive input data protects confidentiality in transit or at rest but does nothing to stop malicious payloads from being interpreted as code by an interpreter. Option C is incorrect because detailed custom error messages can leak schema, stack traces, or query structure to attackers, aiding injection exploitation rather than preventing it; generic error handling is the safer practice.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Encode output to the browser
Why it's wrong here
Output encoding neutralises injected content at the point of rendering, which mitigates cross-site scripting rather than the injection attacks targeted here. It is tempting because encoding is a core defence, and would be the correct practice when untrusted data is written into HTML, SQL or command contexts.
- ✗
Encrypt sensitive input data
Why it's wrong here
Encryption protects data confidentiality in storage or transit; it does not alter how untrusted input is parsed, so injection payloads still execute. It is tempting because encryption is a recognised data-protection control, and would be correct when the requirement is safeguarding sensitive data at rest or in motion rather than validating input.
- ✗
Use custom error messages that detail the failure
Why it's wrong here
Detailed custom error messages leak stack traces, query fragments and schema details that aid injection probing, so they increase rather than reduce risk. It is tempting because verbose errors speed developer debugging, and would be appropriate in isolated development environments, never in production responses.
- ✓
Use parameterized queries or prepared statements
Why this is correct
Parameterised queries bind user input as data rather than executable SQL, so the database engine never interprets it as code. This directly satisfies the stem's constraint of preventing injection attacks, since structural query logic stays fixed while values are passed separately, defeating classic SQL injection.
- ✓
Validate and sanitize all user input
Why this is correct
Validating and sanitising all user input directly satisfies the mandatory practice of preventing untrusted data reaching interpreters. Allow-list validation rejects malformed characters, while sanitisation neutralises residual metacharacters before they reach SQL, LDAP or OS command parsers, blocking injection payloads at the earliest boundary.
Go deeper
Related to this question
Learn chapter
Secure Network Architecture and Components
Key term
Secure coding
Secure coding is the practice of writing software in a way that protects it from vulnerabilities and attacks by following security best practices throughout the development process.
Key term
Vulnerability
A vulnerability is a weakness in a system, network, or software that could be exploited by a threat to cause harm or unauthorized access.
About these practice questions
One of 816 original CISSP 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 CISSP 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 CISSP exam.