Security3 min read
The web application security checklist we run before every launch
Not a compliance document. This is the list we actually work through before a client site handles its first real user.
Secrets belong in a dedicated secret manager, injected into the runtime environment at deploy time, separated per environment, and rotated on a schedule. Never commit them, never bake them into container images, and run automated scanning so a committed credential is detected in minutes rather than discovered in an incident.
| Location | Verdict |
|---|---|
| Committed .env file | Never |
| Local .env, gitignored | Fine for development only |
| CI/CD secret store | Good for deploy-time credentials |
| Platform environment variables | Good for most applications |
| Dedicated secret manager | Best — versioning, audit log, rotation, fine-grained access |
| Container image layers | Never — persists in image history |
The practical target for most teams: a secret manager as the source of truth, synced into the platform's environment variables at deploy time, with the application reading plain environment variables and knowing nothing about the manager.
Rotation limits how long a leaked credential is useful. It only works if the application can tolerate two valid secrets during the changeover — otherwise rotation means downtime, and a rotation that means downtime never happens.
Removing a secret from git history does not un-leak it. Public repositories are scraped continuously by automated tooling, often within seconds of a push.
They are acceptable when injected at runtime from a secure store. The weaknesses are no versioning, no audit trail, no rotation support, and exposure through crash dumps or debug endpoints that print the environment.
Through a CLI that pulls development-tier secrets from the manager into a local session. Sharing .env files over chat is how credentials end up in places nobody can inventory.
Tools like SOPS or git-crypt make it workable, and are a reasonable step up from plaintext. A managed secret service is still better for rotation and access control.
Every 30 to 90 days for static credentials, immediately on suspicion or personnel change. Better still, use short-lived credentials so rotation is continuous and automatic.
ROVQIX Engineering
Engineering team, ROVQIX
The ROVQIX engineering team builds and maintains web platforms, APIs and infrastructure for clients across SaaS, ecommerce and enterprise. These notes come out of real production work — deploys, incidents, migrations and audits.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
Not a compliance document. This is the list we actually work through before a client site handles its first real user.
Container security starts with four lines in a Dockerfile and a scan in CI. Most breaches involve failures at that level, not exotic escapes.
Clicking through a cloud console works right up until you need the same thing again, in another region, at 2am, from memory.
No spam. Just the occasional case study and craft breakdown.