The Practices That Actually Matter

Validate at the boundary

Every piece of external data — request bodies, file contents, API responses, queue messages — should be validated into a known shape before any logic touches it.

A service that validates at the boundary can trust its internals. One that validates ad hoc is where the subtle failures live.

Secrets

1. Never in the repository, including in history
2. Environment variables at minimum, a secrets manager where available
3. Different per environment, so staging cannot touch production
4. Rotatable, and actually rotated
5. Never logged, including in error handlers

Secrets committed to a repository remain in the history after deletion. Rotate them rather than assuming removal was sufficient.

Dependencies

• Automated vulnerability auditing on every build
• Security updates applied within days
• A lock file, so builds are reproducible
• Awareness of what each dependency pulls in transitively
• Fewer dependencies where a small amount of code would do

Authorisation on every action

The most common authorisation failure is checking the action but not the record — a user permitted to view orders viewing someone else's.

Deserialisation and code execution

Never deserialise untrusted data with formats that can execute code, and never pass user input to anything that evaluates it. Both are straightforward to avoid and catastrophic when present.

Use safe data formats, and validate their contents rather than trusting their structure.

Frequently asked questions