Secure Coding Principles
Most of the web vulnerabilities in Chapter 6 trace back to a handful of coding habits, so the cheapest security is writing code that does not create them in the first place. Secure coding is not a separate language — it is a set of durable principles (validate input, encode output, least privilege, fail securely, do not trust the client) applied continuously as Sam writes.
This topic distills those principles into a working discipline and connects them back to the specific flaws they prevent, so security becomes a build-time default rather than a bolt-on.
Validate Input, Encode Output
These are the two habits that kill most injection and XSS (Chapter 6): treat all external input as hostile and validate it, and encode data for the sink it lands in. Nearly every injection bug is one of these two skipped — a query built from unvalidated input, a page rendered without encoding — which is why these two reflexes prevent a disproportionate share of real vulnerabilities.
Least Privilege in Code
Run with the minimum permissions, request the narrowest scopes, use the least-privileged database account — the same principle as Chapter 3, applied so a bug or compromise in the code reaches as little as possible. Least privilege in code means that even when something goes wrong, the payoff is bounded, which is the difference between a contained bug and a full breach.
Fail Securely and Handle Errors
Errors should deny access and reveal nothing sensitive — no stack traces, secrets, or internal detail to the user. A catch block that logs the secret, or an error path that defaults to "allow," is a recurring flaw, because the exceptional path is the one developers test least and attackers probe most. Fail-secure (Chapter 1) is a coding habit as much as an architectural one.
Guardrails and Secure Defaults
Do not trust the client and do not roll your own crypto (Chapter 2): re-check everything server-side and use vetted libraries. And make the safe way the easy way — frameworks that auto-encode, linters and pre-commit hooks that catch dangerous patterns, code review that treats security as first-class. The goal is that Sam falls into the pit of success, where the default path is the secure one and the insecure path takes deliberate effort.
- Trusting input because "it comes from our frontend," ignoring that the client is fully attacker-controllable (Chapter 6).
- Verbose error handling that leaks stack traces, secrets, or internal structure to the user, aiding the attacker.
- Hand-rolling authentication, crypto, or parsing instead of using vetted libraries, reintroducing long-solved flaws.
- Treating secure coding as a review-time gate rather than a default, so the same bug classes recur every sprint.
- Running the app with more permissions than it needs, so a code bug reaches more than it should.
- Validate input and encode output as reflexive habits, mapped to the injection and XSS classes they prevent.
- Apply least privilege in code — scopes, database accounts, permissions — so bugs and compromises reach little.
- Fail securely, handle errors without leaking, and re-verify everything server-side.
- Build guardrails — secure-by-default frameworks, linters, pre-commit hooks, security-aware review — so the safe path is the easy path.
- Use vetted libraries for auth, crypto, and parsing rather than hand-rolled versions.
Knowledge Check
Which two coding habits prevent the largest share of injection and XSS bugs?
- Validating all external input and encoding output for the sink it lands in
- Compressing all responses and aggressively caching every database query result
- Using longer variable names and more comments
- Encrypting the source code repository
Why is verbose error handling a security flaw?
- Leaking stack traces, secrets, or internal structure to the user aids the attacker
- Verbose errors slow the application down
- Errors should always be shown in full to build user trust
- Error handling has no security relevance
What does "the pit of success" mean for secure coding?
- Secure defaults make the safe path the easy one
- Developers should be punished for every insecure commit
- Security should only be checked in a final gate
- Secure code must be written entirely by the security team
You got correct