Many security incidents start not with a sophisticated attack but with a key in the wrong place: in the repository, in a screenshot, in a chat message, in a website’s JavaScript bundle. Secrets management is the discipline that prevents this.
Where secrets live
In the hosting platform’s environment variables, separated by production, preview and development, or in a dedicated vault from which the application reads them at runtime. Not in code, not in configuration files in the repository, not in shared documents. Local development files containing secrets are excluded from the repository.
The public-variable trap
Frameworks distinguish between variables available only on the server and those that reach the browser. In Next.js, variables prefixed NEXT_PUBLIC_ are built into the client bundle and readable by anyone. A database service key with that prefix is published. Keys with elevated privileges are therefore used exclusively server-side.
Least privilege and separation
Each key gets only the rights its purpose needs, and each environment its own keys. A compromised preview key must not grant access to production. For third-party integrations, separate keys per integration pay off, so one can be revoked without affecting the others.
Rotation
Secrets should be replaceable without the application failing — regularly, and immediately when a leak is suspected or a person with access leaves the team. Those who have never practised rotation discover in an emergency in how many places a key was used.
Detecting leaks
Secret detection tools scan commits and history in repositories; many platforms offer this built in. A key that was ever in the repository counts as compromised, even if later removed, because it remains in the history. Then only rotation helps.
Part of data security
Secrets management is one of the technical and organisational measures data protection law requires and belongs in every pre-launch security checklist. Practice on Vercel is described in our article on Vercel deployment patterns.