Secure Coding Practices and Application Architecture
Core concepts
Secure coding is a set of defaults: validate at trust boundaries, encode at sinks, fail securely (deny by default), apply least privilege to processes, services, and database accounts, and avoid security-relevant race conditions (TOCTOU) by making checks atomic. Know secure defaults in frameworks: ORM parameterization, auto-escaping templates, CSRF middleware, secure cookie flags, and dependency pinning. Understand defense in depth and separation of duties across tiers: a web tier should not hold database credentials with DDL rights, and a service should not trust a header set by a client.
Architecture patterns
Know API gateways, service-to-service authentication (mTLS, short-lived tokens), secrets injection at runtime, and the principle that security controls belong in a shared layer rather than copy-pasted per endpoint. Understand error handling that logs details server-side but returns generic messages, and structured logging with correlation IDs. Know that microservices multiply the attack surface and require consistent authn/authz policy.
Traps
Questions equate code review with penetration testing, or assume framework auto-escaping covers every sink (it does not cover innerHTML, raw SQL, or shell calls). Also watch for "fail open" error handling answers and for trusting X-Forwarded-For or role headers from the client.
Rule of thumb
Deny by default, fail closed, and centralize the control so a missed endpoint cannot silently bypass it.
Worked example
A file upload handler checks the extension, then writes the file. An attacker swaps the file between check and write (TOCTOU). Fix: validate and store atomically, generate the server-side filename, and serve uploads from a non-executable location.