Secure Coding

In 2017, Equifax suffered a breach that exposed 147 million Americans' personal data. The root cause: a known vulnerability in Apache Struts (CVE-2017-5638) that had been patched two months earlier. Equifax had not applied the patch. Their dependency scanning process failed. 147 million Social Security numbers, birth dates, and addresses were compromised because nobody ran npm audit (or the Java equivalent).

Secure coding is not a separate activity bolted on at the end of development. It is a set of habits applied to every line of code, every code review, and every deployment pipeline. The principles are straightforward:

1. Never trust input. Validate and sanitize everything from outside your trust boundary. This includes URL parameters, request bodies, headers, cookies, file uploads, and data from other services.
2. Fail securely. When an error occurs, deny access. A crash should lock the door, not leave it open. An unhandled exception should return a 500 error, not bypass authentication.
3. Defense in depth. Multiple independent layers of protection. If input validation misses a payload, parameterized queries stop SQL injection. If parameterized queries are bypassed (legacy code), least-privilege DB accounts limit damage.
4. Least privilege. Every process, account, and API key runs with the minimum permissions needed. Your web server does not need root. Your database account does not need DROP TABLE.
5. Keep it simple. Complex code has more bugs, including security bugs. Every conditional branch is a potential place where a security check might be missing. Simpler code is easier to audit.

The OWASP Top 10 is a consensus list of the most critical web application security risks, updated every few years based on real-world vulnerability data. Security auditors use it as a checklist. Job interviewers ask about it. If you build web applications, you need to know these ten categories.

The 2021 edition (still current as of 2026) reorganized significantly. Broken Access Control moved to #1 because 94% of tested applications had some form of it. Injection dropped to #3 because frameworks now parameterize by default. Insecure Design was a new addition, recognizing that some security flaws are architectural and cannot be fixed by better coding.

Understanding the top 5 gives you coverage for the majority of real-world vulnerabilities:

#1 Broken Access Control. Users access resources they should not. Missing authorization checks on API endpoints. Direct object reference without ownership verification. The fix: deny by default, check ownership on every resource, enforce server-side.

#2 Cryptographic Failures. Weak hashing (MD5/SHA1), missing encryption at rest, plaintext passwords in logs. The fix: AES-256 at rest, TLS 1.3 in transit, bcrypt or Argon2id for passwords.

#3 Injection. SQL injection, command injection, LDAP injection. User input treated as code. The fix: parameterized queries, never concatenate user input into commands.

#4 Insecure Design. Architecture flaws that no amount of code fixes can solve. A password reset flow using sequential tokens (1001, 1002, 1003) is fundamentally broken. The fix: threat modeling before writing code.

#5 Security Misconfiguration. Default passwords in production, verbose error messages, unnecessary features enabled, missing patches. The fix: automated config scanning, hardened defaults, deny by default.