Secure Software Implementation
Code is where abstractions meet reality
Implementation questions test whether you can prevent classes of defect rather than recite a vulnerability list. Know CWE as a weakness taxonomy and the OWASP Top 10 as risk awareness categories, and be able to map a coding mistake to its class.
The dependable core practices: validate input against an allowlist at every trust boundary, principally server side; encode output for its destination context (HTML, SQL, shell, LDAP, XML). Validation and encoding are different controls solving different problems. Use parameterized queries and prepared statements. Use vetted cryptographic libraries with correct modes, unique nonces, and keys held in a secrets manager rather than source or client code. Hash passwords with a salted, deliberately slow algorithm (bcrypt, scrypt, Argon2) - never encrypt or fast-hash them. Handle errors without leaking internals and fail safe. Log security events without sensitive data. Avoid race conditions, integer overflows, unbounded resource allocation, and unsafe deserialization; manage memory safely in unmanaged languages.
Verify with peer review, static analysis in the IDE and pipeline, and dependency scanning. Harden the build with compiler flags, removal of debug code, and minimized attack surface.
Traps
- Blacklist validation ('block the script tag') fails; allowlists survive.
- Client-side validation is usability, not a control.
- Catching an exception and continuing can convert a failure into a privilege bypass.
Rule of thumb
Canonicalize, then validate against an allowlist, then encode for the exact output context - three steps, in that order, stop most injection defects.