City developers are wiring a new payment callback that builds database queries from raw request fields. What source-level issue must secure coding prevent?
Select an answer to reveal the explanation.
Short Explanation
Gluing user input straight into queries is how payment pages become attacker playgrounds. Injection, unsafe deserialization, and friends are source-level landmines. Secure coding stops them in the editor—not in the incident report.
Full Explanation
Secure coding must prevent injection flaws, insecure deserialization, and similar source-level weaknesses when developers build payment callbacks from raw request fields. Concatenating untrusted input into queries or commands enables injection; careless deserialization of attacker-controlled objects can yield remote code execution; related issues include XSS, SSRF, and path traversal when inputs are trusted implicitly. Payment callbacks are high-value targets because they influence financial state—defensive coding, parameterized queries, allowlists, and safe serializers are mandatory.
Overuse of CSS animations on the confirmation page is a UX concern, not the source-level security class at issue.
Choosing an unpopular color palette for accessibility may affect usability perception but is not the injection/deserialization problem described.
Running too many successful unit tests before merge is not a vulnerability class; tests are generally beneficial and unrelated to the insecure pattern of trusting raw request fields in query construction.
Exam caveat: CISSP Domain 8 expects recognition of classic secure-coding failures—injection and insecure deserialization foremost among source-level issues. Operational check: ban string-built SQL/commands in standards, require code review on payment paths, add SAST rules for injection sinks, use typed DTOs with validation, and never deserialize untrusted payloads into executable object graphs in municipal payment flows.