Secure Coding

SQL injection, cross-site scripting, command injection, and the classic buffer overflow look like four different bugs, but they are one event wearing four costumes: data an attacker controls reaches code that treats it as trusted. Read any source-level vulnerability scenario through that lens and you can name the weakness class and predict its root-cause defense before the answer options load, because the durable fix always breaks the same chain at the point of consumption, not at the list of payloads. That one idea, paired with the CIA triad and layered defense-in-depth you already know, unifies the entire subtopic. SQL injection is attacker input reaching a database query; cross-site scripting (XSS) is attacker input reaching an HTML page; command injection is attacker input reaching a shell; a buffer overflow is attacker input reaching a fixed-size memory region. The figure shows the model: untrusted input first passes a cross-cutting input-validation gate, and whatever survives reaches a sink that has its own root-cause defense.

Two cross-cutting defenses recur often enough to name once here and reuse throughout. The first is input validation, and the load-bearing detail is its direction: validate against an allow-list of known-good input (the precise format, length, and character set you expect), not a deny-list of known-bad characters, because you cannot enumerate every malicious input an attacker might craft, so a deny-list always has a gap. The second is context-aware output encoding: when data leaves your application into another interpreter (a browser, a query, a shell), encode it so that interpreter renders it as inert data rather than executable instructions. Input validation constrains what comes in; output encoding neutralizes what goes out. Neither alone is complete, which is why defense in depth pairs them.

The rest of this page applies that model in three passes: the per-weakness mechanics (the canonical defense for each named vulnerability class), the API and software-defined-security surfaces where the same defenses move to a new boundary, and the exam-pattern recognition that turns the model into points. Throughout, defenses are stated at CISSP altitude (parameterize the query, encode for the context, enforce authorization server-side) never as a single language's syntax.

This section gives the canonical, root-cause defense for each named weakness class, and the taxonomies that let tools and teams refer to them precisely. It reuses the input-validation and output-encoding model from the previous section without re-deriving it.

Injection: separate code from data

Injection is the archetype. For SQL injection, OWASP's primary defense is the prepared statement with parameterized queries, because it forces "the developer to define all SQL code first and pass in each parameter to the query later^[1]," so that "the database will always distinguish between code and data, regardless of what user input is supplied." That separation is why "an attacker cannot change the intent of a query, even if SQL commands are inserted." OWASP's priority order is explicit: prepared statements first, then safely-implemented stored procedures, then allow-list input validation for the cases where a bind variable cannot be used (e.g. a table name), and escaping user input is "STRONGLY DISCOURAGED" as a fragile, database-specific last resort. The same code-versus-data principle generalizes: OS command injection is defeated by avoiding the shell and calling a parameterized command API with an allow-list of arguments; LDAP injection by escaping for the LDAP context.

Cross-site scripting: encode for the destination context

XSS is injection into a web page: untrusted input is reflected into HTML and the browser executes it as script. The defense is output encoding that matches where the data lands, because the parsing rules differ by context and "wrong encoding methods may introduce weaknesses^[2]": HTML-body encoding converts < to <, an HTML-attribute context needs attribute encoding, a JavaScript context needs JavaScript encoding, and a URL context needs percent-encoding; they are not interchangeable. Input validation is a useful defense-in-depth layer but cannot be the sole control, since "context awareness cannot be determined at the HTTP request layer^[2]" where input validation runs. A Content Security Policy is a further mitigating layer. In the OWASP Top 10:2021 taxonomy, XSS is folded into the Injection category rather than standing alone.

Broken access control: enforce authorization server-side, every request

Broken access control is the failure to enforce that "users cannot act outside of their intended permissions^[3]." It is the #1 risk in the OWASP Top 10:2021, having "moved up from the fifth position," with "94% of applications^[3] tested for some form of broken access control." The coding defenses are structural: deny by default, enforce authorization on the server for every request (never trust a hidden form field, a disabled button, or a client-side check), and check ownership before acting on an object so a user cannot read or modify another user's record by changing an identifier.

Memory-safety weaknesses: bounds and range checks

A buffer overflow writes past the end of a fixed-size buffer because no bounds check constrains the write; the consequences range from a crash to attacker code execution by overwriting a return address. The root-cause defenses are bounds checking and memory-safe languages or functions; compiler and OS mitigations (stack canaries, Address Space Layout Randomization, and Data Execution Prevention / non-executable stacks) raise the bar but do not remove the flaw. An integer overflow is arithmetic that exceeds the type's range and wraps silently, often producing an undersized allocation or a bypassed length check that then enables a buffer overflow, so range and overflow checks belong before the value is used to size or index memory. A race condition / time-of-check-to-time-of-use (TOCTOU) flaw arises when state changes between a security check and the action that relied on it; the fix is to make check-and-act a single atomic operation (locking, atomic APIs) rather than two separable steps.

The taxonomies: what each artifact is FOR

Four names recur, and the exam tests whether you know which is which. The OWASP Top 10 is "a standard awareness document for developers and web application security^[4]": a ranked awareness list of risk categories, not a checklist. CWE (MITRE's Common Weakness Enumeration) is the dictionary of weakness types: CWE-89 is SQL injection, CWE-79 is XSS, CWE-120 is a classic buffer overflow, a stable identifier tools and reports cite to name a defect precisely. CVE is a different thing entirely: one specific vulnerability instance in one product (a CVE is an instance of a CWE). The OWASP Application Security Verification Standard (ASVS) is a tiered catalog of security requirements you verify an application against, and CERT/SEI secure coding standards give language-specific rules. Top 10 = themes, CWE = named weaknesses, ASVS = requirements to verify, CVE = one real-world instance. The figure groups those weakness classes into families, each weakness paired with the structural defense the exam rewards.

This section moves the same defenses to two surfaces the exam treats as distinct: the API call boundary and security expressed as code. It introduces no new defense principle, only new places the principles apply.

API security: authorize the object, not just the caller

An API exposes application logic directly to programmatic callers, so the controls are the same authentication, authorization, validation, and rate-limiting you already know, applied at every call. The OWASP API Security Top 10 (2023) names the dominant failures, and the top one is Broken Object Level Authorization (API1:2023): an authenticated user requests another user's object simply by changing an ID in the request, because the server authenticated the caller but never checked that this caller may access that object. The fix is an ownership/authorization check on every object reference, server-side. A related entry, Broken Object Property Level Authorization (API3:2023), combines the older 'excessive data exposure' and 'mass assignment' problems: returning or accepting more object fields than the caller should see or set, then relying on the client to filter. Unrestricted Resource Consumption (API4:2023) is why rate limiting is a first-class API control: without it, an API request that consumes "network bandwidth, CPU, memory, and storage^[5]" can be driven to a denial of service or a brute-force of credentials. Schema-based request validation (rejecting any request body or parameter that does not match a declared schema) is the input-validation gate from the model section, expressed for APIs.

Software-defined security: controls as version-controlled code

Software-defined security expresses security controls as code and configuration rather than hand-applied settings, so they are version-controlled, peer-reviewed, tested, and applied identically across every environment. Policy-as-code evaluates a declarative policy in the deployment pipeline; infrastructure-as-code templates define network segmentation, identity, and security-group rules as files that go through the same review and audit as application code. The security payoff is twofold: consistency (the same control everywhere, no drift between a hand-configured production box and its staging twin) and auditability (every change is a reviewable, attributable commit). This is the secure-coding mindset applied to the platform: the configuration that enforces a control is itself code, so it inherits code's review, testing, and rollback discipline. The figure groups the two surfaces: each API failure beside its server-side fix, and the two code-as-control forms beside the consistency and auditability they buy.

This section turns the model into points: it names the stems the exam uses and the trap each one dangles. It introduces no new facts; every claim traces to a section above.

Name the weakness, then pick its root-cause defense

The stem describes a flaw; map it to the defense the exam rewards. Untrusted input concatenated into a database query → SQL injection (answer: parameterized query / prepared statement, not 'escape the input' and not 'add a WAF'). User input reflected into a page and executed by the browser → XSS (answer: context-aware output encoding for where the data lands; input validation is only defense in depth). A user reaching another user's record by changing an ID → broken object-level authorization / broken access control (answer: server-side authorization check on every object, deny by default). Writing past a fixed-size buffer → buffer overflow (answer: bounds checking / memory-safe language; canaries, ASLR, DEP are hardening layers). Two steps with a gap between check and use → race condition / TOCTOU (answer: make check-and-act atomic).

The traps, stated as the wrong move

• Reaching for a deny-list (blocklist) of bad characters: choosing 'strip dangerous characters' or 'block known-bad input' when the defensible answer is an allow-list of known-good input; you cannot enumerate all bad input.
• Escaping instead of parameterizing for SQL injection: picking 'escape single quotes' when prepared statements are the primary defense and escaping is OWASP-discouraged and fragile.
• Treating a WAF as the fix rather than a compensating layer: a web application firewall buys time, but the root-cause control is the secure-coding practice (parameterize, encode, authorize); 'add a WAF' is the distractor when the stem describes a code-level flaw.
• Validating input but forgetting context-specific output encoding for XSS: input validation cannot be the sole XSS control because context awareness is not available at the request layer; the answer must include encoding for the output context.
• Authenticating the caller but not authorizing the object: assuming a logged-in user is allowed to act on any object they can name; object-level authorization must be checked per request.
• Confusing the taxonomies: answering 'CVE' when the question wants the weakness type (CWE), or treating the OWASP Top 10 as a compliance checklist rather than an awareness ranking.

When the question is testing a neighbor, not this subtopic

If the stem is about the tool that finds the flaw (static analysis (SAST), dynamic analysis (DAST), fuzzing, software composition analysis) that is dev-environment-security / software-security-effectiveness, not secure coding. If it asks where in the lifecycle security belongs (threat modeling, security requirements, shifting left), that is sdlc-security. If it asks about risk in purchased or imported components (SBOM, third-party/open-source evaluation), that is acquired-software-security. This subtopic owns the code you write and the source-level weakness classes within it.