CISSP Software Development Security Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Encoding input before processing

  Why it's wrong here

  Encoding input before processing is an incorrect security practice for input validation. Encoding transforms special characters into a safe representation for a specific context, like HTML entities or URL encoding, but it does not validate the input's intent or content. A malicious payload, even if encoded, can still be decoded and executed by the application or underlying interpreter if it's not properly validated against expected patterns *before* any processing occurs. This approach merely shifts the problem without addressing the root cause of untrusted input.

• ✗

  Using regular expressions to sanitize input

  Why it's wrong here

  Regular expressions for input sanitisation attempt to remove or block malicious characters, but injection attacks exploit context-specific parsing (e.g., SQL, LDAP, or shell interpreters) that regex cannot reliably anticipate across all encoding layers. This approach is tempting because regex effectively validates format constraints (e.g., email patterns) in static data, where character whitelisting is sufficient. It would be correct for preventing format-based injection in a single, well-defined context like a numeric ID field.

• ✗

  Blacklist validation to block known malicious patterns

  Why it's wrong here

  Blacklist validation, which attempts to block known malicious patterns, is inherently flawed and provides insufficient security. This reactive approach relies on maintaining an exhaustive list of all possible bad inputs, which is practically impossible to achieve. Attackers can often bypass blacklists by using novel attack vectors, different encodings, or obfuscation techniques not present in the predefined list, leaving the application vulnerable to new or cleverly disguised threats. It creates a false sense of security by focusing on what *not* to allow, rather than what *is* allowed.

• ✓

  Whitelist validation to allow only known good patterns

  Why this is correct

  Whitelist validation is considered the most robust and secure approach for handling user input. This method explicitly defines and permits only a specific set of known-good, expected characters, formats, or values that the application is designed to accept. Any input that deviates from this precisely defined safe set is rejected by default. This proactive "allow-by-default" strategy effectively prevents unknown or novel attack vectors, as anything not explicitly allowed is implicitly denied, making it highly resilient against various injection and manipulation attempts.

Go deeper

Related to this question