Web applications depend on secrets: database passwords, API tokens, signing keys, payment credentials, SMTP passwords, deployment tokens, and cloud access keys. The security problem is not that secrets exist. It is that they are often copied into source code, local files, build logs, browser bundles, support tickets, chat messages, and deployment artifacts until nobody knows which copy is authoritative or who can still use it.
A mature secrets-management process reduces the number of places a secret can exist, controls who and what can retrieve it, rotates it when exposure is plausible, and keeps privileged credentials away from client-side code. This guide focuses on practical web-development workflows rather than any one vendor or secret-management product.
What should be treated as a secret?
- Database credentials and connection passwords.
- Cloud access keys and service-account credentials.
- Payment gateway and webhook signing secrets.
- JWT signing keys and private cryptographic keys.
- SMTP passwords and email-provider API tokens.
- Deployment and package-registry tokens.
- Third-party API keys that grant privileged access or paid usage.
- Session signing or encryption keys.
- Private monitoring, backup, and storage credentials.
Not every identifier named API_KEY is secret. Some browser SDKs use public identifiers by design. The correct question is what the value authorizes. If possession grants privileged access, billable operations, data access, signing authority, or administrative control, treat it as a secret.
Do not put private secrets in frontend bundles
Anything delivered to the browser can be inspected by the user. Minification, obfuscation, source-map removal, and hidden environment-variable names do not create confidentiality. A frontend application should call a backend that holds the privileged credential when the operation requires secrecy.
Browser
-> your backend API
-> privileged third-party API using server-held secret
Not:
Browser
-> privileged third-party API with embedded private keyIf a third-party service requires a browser-visible key, configure the provider's supported domain restrictions, scopes, quotas, or public-client model. Do not assume the key is confidential simply because it appears inside bundled JavaScript.
Use .env files carefully
.env files are convenient for local development, but convenience can become exposure when the file is committed, copied into an image layer, included in an archive, or placed under the public web root. Add local secret files to version-control ignore rules and keep production secrets in a controlled deployment mechanism.
The Exposed Paths Checker can help identify public exposure of common sensitive paths, but the better control is preventing secret files from being deployed publicly in the first place. If a production .env file has been reachable, rotate the secrets it contains rather than only changing the web-server rule.
CI/CD secrets need their own trust model
Build pipelines often have broad access because they deploy production. Limit secret scope to the jobs, environments, and repositories that require it. Protect production environments with approvals where appropriate and avoid printing secret values in logs.
- Use environment-specific credentials.
- Restrict production deployment tokens to protected branches or workflows.
- Prefer short-lived or federated credentials when the platform supports them.
- Mask secrets in logs, but do not rely on masking as the only control.
- Rotate credentials when pipeline compromise is suspected.
- Remove obsolete secrets rather than keeping them indefinitely.
Be especially careful with pull-request workflows from forks or untrusted contributors. A build job that exposes production secrets to untrusted code can turn a normal contribution path into credential theft.
Design rotation before an incident
A secret that cannot be rotated safely becomes operational debt. Document who owns each credential, where it is used, how to replace it, and what services must be restarted or redeployed. Where possible, support an overlap period so an old and new credential can coexist briefly during rotation.
Inventory entry:
Name: payment-webhook-signing-secret
Owner: payments team
Used by: checkout webhook service
Storage: production secret manager
Rotation: scheduled and on exposure
Revocation test: documentedRotation plans should include failure handling. If a credential is replaced and one old worker still depends on it, the team needs a way to detect that dependency without restoring the compromised value globally.
Make credentials least privilege
A token used only to send transactional email should not also administer the entire email account. A deployment token for one repository should not grant organization-wide source access. Scoping reduces the impact when a credential leaks and makes incident response more targeted.
Hypothetical scenario: private API key compiled into JavaScript
A team integrates a data provider. During development, the quickest solution is to set VITE_PROVIDER_ADMIN_KEY and call the provider directly from the React frontend. The key works, so the feature ships.
Because the build tool intentionally exposes prefixed environment variables to browser code, every user receives the key in the JavaScript bundle. Removing a source map later does not solve the problem. The credential is already public.
The proper response is to revoke the exposed key, move privileged API calls to a backend, issue a narrowly scoped server credential, add rate and authorization controls to the backend endpoint, and add a build check that rejects known secret patterns in client assets. The team should also review earlier deployment artifacts because old bundles may still contain the key.
Secrets in repository history
Deleting a secret from the latest commit does not necessarily remove it from repository history, forks, CI logs, package artifacts, or developer clones. Revoke the credential first. History rewriting can reduce future discovery, but it is not a substitute for invalidating the exposed value.
Repository secret scanning is useful for prevention and detection, but treat findings as credential incidents. A scanner can tell you that a token-shaped value exists. The owner still needs to determine whether it was valid, what it authorized, how long it was exposed, and whether it was used unexpectedly.
Keep secrets out of logs and support workflows
Authorization headers, connection strings, private tokens, and signed URLs can leak through verbose logs. Review application logging so sensitive headers and fields are redacted before storage. Support teams should have a safe process for customers to provide diagnostics without pasting production secrets into tickets.
Redaction should happen before data enters long-retention log systems where possible. Deleting a secret from one dashboard later may not remove copies from exports, archives, alert payloads, or downstream analytics systems.
Check container images and build layers
Secrets copied during a container build can survive in image layers even if a later step deletes the file. Avoid baking production credentials into images. Inject secrets at runtime using the orchestration platform's supported secret mechanism and keep image registries and build logs under appropriate access control.
Review what the browser exposes
Use the JS Library Vulnerability Checker and Technology Fingerprint for related public frontend context. These tools do not perform repository secret scanning, but they can help you understand what client-side technologies and version signals are exposed.
What to do after a secret leak
- Revoke or rotate the credential as the first containment step.
- Determine what privilege the credential granted.
- Review logs for suspicious use during the exposure window.
- Remove the secret from source, artifacts, logs, or public files.
- Update affected deployments with the replacement credential.
- Check whether related credentials share the same password or key material.
- Record the root cause and add a prevention control.
- Retest the public site for exposed artifacts.
How Vulnify fits into secrets hygiene
Vulnify is not a repository secret manager and should not be presented as one. Its value is on the public surface. The Exposed Paths Checker can identify supported public artifact exposures, and the broader Website Security Scanner can assess additional external weaknesses around the deployed application.
Internal controls still need a secret manager, repository scanning, CI/CD governance, identity management, and rotation procedures suited to your environment. Public scanning complements those controls by showing what escaped into the internet-facing deployment.
Secrets-management checklist
- Inventory privileged secrets and owners.
- Keep private secrets out of frontend code.
- Keep local secret files out of repositories and public deploy artifacts.
- Scope credentials to the minimum required privilege.
- Use environment-specific credentials.
- Restrict CI/CD secret access.
- Redact secrets before logging.
- Design and test rotation procedures.
- Revoke exposed credentials instead of only deleting files.
- Review public deployments after incidents or migrations.
Maintain a secret inventory with clear ownership
Secrets become difficult to protect when nobody knows which application owns them or where they are used. Maintain an inventory that records the secret purpose, owning service, environment, rotation method, last rotation date, and systems that consume it. Do not store the secret value in the inventory itself. The inventory should point to the approved secret-management location and responsible owner.
This makes incident response much faster. If a repository, developer laptop, CI runner, or public bundle is suspected of exposure, the team can identify exactly which credentials may be affected and rotate them in a controlled order instead of replacing every credential blindly. Ownership also prevents stale API keys from surviving long after an integration has been removed.
Conclusion
Good secrets management is mostly about reducing uncontrolled copies and designing for rotation. Keep privileged credentials on trusted server-side systems, scope them narrowly, protect CI/CD access, prevent secret files from entering public artifacts, and revoke credentials quickly when exposure is plausible. A secret that can be copied everywhere and cannot be rotated safely is a future incident waiting for the wrong deployment or compromised account.