Best practices · Security
Secrets Management Best Practices
Opens with creditsA practical guide to secrets management for developers who build and deploy apps. It covers where secrets should live, keeping them out of git and catching leaks, least privilege, rotation, CI/CD with OIDC instead of long-lived keys, what the browser can and cannot see, log redaction, and what to do in the first hour after a leak.
Written by Tauseef Fayyaz7 chapters, 28 practicesAbout 19 min25 quiz questionsReviewed 12 October 2026What you will learn
7 chapters · about 19 min
1Where secrets should liveThe right home for a secret depends on the size of your team and setup, but there are a few places a secret should never be.5 practices · 4 min
- 1Never commit secrets to git, even in private repositories
- 2Use a secrets manager once more than one person or service needs a secret
- 3Inject secrets at runtime instead of baking them into builds
- 4Use different secrets for development, staging and production
- 5Keep an inventory of every secret, its owner and where it is used
5 in this chapterOpen this chapter2Catching leaks before and after they happenTools that stop secrets reaching a repository, and the order of steps when one gets through.4 practices · 3 min
- Least privilege and short-lived credentialsLimit what each secret can do and how long it works, so a leak causes as little damage as possible.4 practices · 3 minOpens with credits
- RotationReplacing secrets on a schedule and on demand, without downtime.3 practices · 2 minOpens with credits
- CI/CD secrets and OIDCPipelines hold the keys to production, so treat them like production: short-lived credentials, narrow trust and reviewed changes.5 practices · 3 minOpens with credits
- Frontend versus backend secretsAnything shipped to the browser or a mobile app is public. This chapter is about drawing that line clearly.4 practices · 2 minOpens with credits
- Logging, redaction and incident responseKeep secrets out of the logs you collect, and know exactly what to do in the first hour after a leak.3 practices · 2 minOpens with credits
About this guide
Secrets management is how you store, share, use and replace the credentials your software runs on: database passwords, API keys, signing keys and cloud tokens. Most real leaks are not clever attacks. They are an .env file committed to a public repo, a key printed in a CI log, or a "public" environment variable that was never meant to reach the browser. Good secrets management best practices make those mistakes hard to make and cheap to recover from.
This guide starts with the two things that prevent most incidents: putting secrets in the right place, and keeping them out of git with scanning and push protection. It then covers least privilege, rotation, CI/CD pipelines that use OpenID Connect (OIDC) instead of stored cloud keys, the line between frontend and backend secrets, log redaction, and a step-by-step response for when a secret leaks anyway.
The advice follows the OWASP Secrets Management Cheat Sheet, GitHub's documentation on secret scanning, push protection and OIDC, and cloud vendor guidance such as AWS Secrets Manager. Each practice tells you what to do and how to check you have done it.
Common questions
Is it safe to store secrets in environment variables?
Environment variables are an acceptable way to pass secrets to a server process, as long as the values come from a secret store at deploy or start time and are never committed or baked into builds. For containers, files mounted from a secret store are safer, since they do not appear in process listings or docker inspect output.
What should I do if I accidentally pushed an API key to GitHub?
Revoke or rotate the key with the provider immediately, then deploy the replacement. Removing it from git history is secondary, because clones and scanners may already have it. Check the provider's logs for any use of the old key.
Are NEXT_PUBLIC_ environment variables secret?
No. Next.js inlines NEXT_PUBLIC_ variables into the JavaScript sent to the browser at build time, so anyone can read them. Keep secrets in variables without the prefix and use them only in server code.
What is OIDC in GitHub Actions?
OpenID Connect lets a GitHub Actions job get a short-lived token from your cloud provider instead of using stored access keys. The cloud provider checks claims such as the repository and environment before issuing credentials that last only for that job.
How often should I rotate secrets?
Rotate immediately when a secret may be exposed or someone with access leaves. For routine rotation, automate it where your provider supports it; every 30 to 90 days is a common schedule for keys and database passwords. Short-lived credentials remove the need for most manual rotation.
What is the best way to store secrets for a small project?
Use your hosting platform's encrypted environment variables (Vercel, Netlify, Render and similar) for deployed values, a git-ignored .env for local development, and an .env.example in the repo. Move to a dedicated secrets manager when several services or people need the same secrets.
Sources (8)
Checked against these, last on 12 October 2026.
- Secrets Management Cheat Sheet, OWASPcheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
- About secret scanning, GitHub Docsdocs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
- About push protection, GitHub Docsdocs.github.com/en/code-security/secret-scanning/introduction/about-push-protection
- OpenID Connect, GitHub Docsdocs.github.com/en/actions/concepts/security/openid-connect
- Using secrets in GitHub Actions, GitHub Docsdocs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets
- Deployments and environments, GitHub Docsdocs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
- Rotate AWS Secrets Manager secrets, AWSdocs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html
- How to use environment variables in Next.js, Next.js docsnextjs.org/docs/app/guides/environment-variables
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Authentication Best PracticesBuild sign-in that holds up: password rules from NIST, Argon2id hashing, login throttling, MFA and passkeys, secure sessions and safe account recovery.
- Secure Coding Best PracticesWrite code that resists attack: untrusted input, validation, parameterized queries, output encoding, safe parsing, uploads, SSRF and errors that fail closed.
- Authorization Best PracticesGet access control right: deny by default, object-level checks against IDOR, RBAC vs ABAC vs ReBAC, tenant isolation with row-level security, audits and tests.
Checklists
See all- Linux Server Hardening ChecklistHarden an Ubuntu, Debian or RHEL server step by step: accounts and sudo, SSH, updates, firewall and open ports, permissions, logging and CIS benchmark scans.
- Software Supply Chain Security ChecklistCheck your dependencies and builds before a release: lockfiles, update bots, pinned actions, CI permissions, SLSA provenance, Sigstore signing, SBOMs and a plan for a compromised package.
- Web Application Security ChecklistA practical web application security checklist built on the OWASP Top 10:2025 and ASVS 5.0, with a severity and a way to verify every check.
Project structures
See all- Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
- Kubernetes with Helm project structureA Helm chart repository for one app: the chart that
helm creategives you, grown into a tested, versioned package with per-environment values, unit tests, install tests in a kind cluster and releases to an OCI registry. For students who can write a Deployment by hand and want to know how a team organises charts. It is about the repo layout and what each file does, not about cluster design. - Firebase (Cloud Functions and security rules) project structureFor students building an app on Firebase who need a real backend: Cloud Functions (2nd gen) in TypeScript, Firestore and Storage security rules with tests, and the Local Emulator Suite. The tree starts from
firebase initand grows into feature folders of callables, triggers and scheduled jobs, then adds CI deploys, environments, contract tests and runbooks.
Career questions
See all- How do I get into AI security as a student or junior engineer?Build a normal security or software foundation first, then learn how LLM apps fail using the OWASP Top 10 for LLM Applications and MITRE ATLAS, and prove it by building, testing and hardening a small LLM app of your own. Most people reach AI security through AppSec, security engineering or ML engineering, not straight from university.
- Where do I start if I want a career in cybersecurity or IT operations?Start with the foundations both fields share: networking, Linux, and how systems fail. Then choose an entry role such as SOC analyst, IT support or junior cloud operations, and prove it with hands-on labs and one documented project rather than a stack of certificates.
- Can I use AI coding tools at my internship, and what should I never paste into them?Usually yes, but only the tools your company has approved, on the code and data they allow, and in the way they allow. Ask in your first week. Never paste secrets, customer data or code you are not permitted to share, and review everything the tool writes as if your name is on it, because it is.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com