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
- Never in the repository, including in history
- Environment variables at minimum, a secrets manager where available
- Different per environment, so staging cannot touch production
- Rotatable, and actually rotated
- 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
| Check | Where |
|---|---|
| Is the caller authenticated? | At the boundary |
| May they perform this action? | In the handler |
| May they access this record? | In the query |
| Is the input within their scope? | Before acting |
| Was it logged? | After acting |
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.