What It's About and Why It Matters for API Security

A secret authenticates a caller to an API. Whoever knows it is treated as a legitimate caller - an API key, a bearer token, or a database connection string must therefore be treated like a password. Secrets management is the organized response to the risk of disclosure (see key leakage): centrally generating, storing, provisioning, auditing, and rotating these secrets instead of keeping them scattered and hardcoded.

According to OWASP, secrets have been used everywhere since the DevOps trend took hold: API keys, database credentials, IAM permissions, SSH keys, and certificates. Many organizations encode them in plaintext in the source code or scatter them across configuration files. OWASP therefore explicitly cites the growing need to centralize storage, provisioning, auditing, rotation, and management in order to control access and prevent leaks.

The connection to API security is direct: the OWASP API Security Top 10 lists, among other things, weak encryption keys and sending auth tokens in the URL as vulnerabilities under API2:2023 (Broken Authentication), and API8:2023 (Security Misconfiguration) demands end-to-end TLS encryption and correctly configured permissions on cloud services. Secrets management addresses exactly these points on the defensive side.

AspectStatic secret (e.g. fixed API key)Dynamic/short-lived secret
LifetimeLong, often unlimited until manual rotationShort, tied to session/lease, expires automatically
Risk if stolenValid until rotation/revocationAlready expired by the next restart or end of lease
RotationShould be automated (e.g. AWS Secrets Manager, Lambda)Inherent through regeneration, e.g. Vault Secrets Engine
Typical storage locationCloud secret manager or vault, never in code/GitVault/KMS generates on demand, in-memory delivery
OWASP recommendationAcceptable with rotation and least privilegePreferred where possible

Static vs. dynamic secrets and storage locations

Centralize and Standardize: Vaults and Cloud KMS

OWASP recommends centralizing and standardizing the secrets management solution. In practice, that means a dedicated system as the single source of truth instead of secrets in .env files, CI variables, and configuration management tools. Common building blocks are:

  • Dedicated vaults such as HashiCorp Vault or CyberArk Conjur. In Vault, secrets engines provide data; some merely store it, others generate dynamic credentials on demand or offer encryption as a service. If a secrets engine is disabled, the associated secrets are - where supported - revoked.
  • Cloud KMS and secret managers such as AWS Secrets Manager, Azure Key Vault, and Google Secret Manager. OWASP advises preferring the cloud provider's own solution for automatic rotation, since the barrier to entry and the risk of misconfiguration are lower.

Standardization can span several solutions (cloud-native plus an in-house system), as long as the interaction stays consistent. Important: the master secret of the central solution must itself be protected elsewhere - for example, the cloud provider's root credentials in a second system.

Short-Lived and Dynamic Credentials Instead of Static Keys

The most effective lever is reducing human interaction with the actual secret. OWASP names three approaches:

  • Dynamic secrets: on startup, an application requests fresh credentials for its session. If stolen database credentials are compromised, according to OWASP they are already expired by the next restart. This shrinks the attack surface for credential reuse.
  • Automated rotation of static secrets: manual rotation is error-prone; it should be automated. AWS Secrets Manager, for instance, offers managed rotation or rotation via a Lambda function in several steps (create new secret, set, test, finish).
  • Secrets pipeline: generation and rotation run through an automated process, not by hand.

In addition: passwordless mechanisms such as OpenID Connect don't replace every type of secret (API keys and DB credentials remain), but they do reduce the attack surface, since OIDC tokens are typically short-lived. Bearer tokens still need to be protected: transmit only over TLS, don't store in browser local storage, validate signature, issuer, and audience, use short lifetimes, and rotate refresh tokens.

Lifecycle: Generation, Rotation, Revocation, Expiration

OWASP describes a clear secret lifecycle, enforced through the central solution's policies:

  • Generation: cryptographically robust and with minimal privileges for the intended purpose; secure transmission over an authenticated channel.
  • Rotation: regular, so that stolen credentials are valid for only a short time. Lifetimes range from minutes to years depending on the function. Machine secrets should rotate regularly; according to NIST, pure user credentials should only be rotated when compromise is suspected. For cryptographic key material, NIST SP 800-57 Part 1 provides the foundations for cryptoperiods and rotation.
  • Revocation: securely revoke secrets that are no longer needed or potentially compromised; for TLS certificates, this includes certificate revocation.
  • Expiration: give secrets an expiration date wherever possible; applications should check whether the secret is still active before trusting it.

Across the board, TLS everywhere applies - never transmit secrets in plaintext - along with tamper-proof auditing: who requested which secret, when, for which system/role, whether it was approved, when it was used, when it expired, and whether there were attempts to reuse expired secrets.

No Hardcoding: Keep Secrets Out of Code, Git, and Logs

Secrets belong neither in shipped client/mobile code, nor in version control, nor in logs. Specifically:

  • Don't check into Git: even after deletion, a secret remains discoverable through the Git history. CI/CD tools should source secrets from a secret manager; OWASP stresses that storing them in CI/CD tooling configuration (e.g. GitHub/GitLab secrets) is not the same as checking them into code, but still requires hardening, least privilege, logging, and rotation.
  • Not in URLs or query parameters: they end up in server, proxy, and browser logs. OWASP API2:2023 explicitly lists sending auth tokens in the URL as a vulnerability.
  • Don't log in plaintext: mask or remove tokens, passwords, connection strings, and encryption keys before logging.
  • Harden the CI/CD pipeline: treat it like a production system, enforce least-privilege access, make sure pipeline output doesn't leak secrets, and ensure forks don't copy secrets.

Ideally, CI/CD never touches the secret itself, but only instructs the orchestration layer (e.g. Kubernetes) to start a service with a service account that the consumer then uses to retrieve the secret itself - a pattern that also underlies the sidecar approach (e.g. a Vault Agent that writes secrets to an in-memory volume).

Least Privilege, Secret Scanning, and Incident Response

Three supporting disciplines round out secrets management:

Least Privilege and Access Control

As soon as a human can read or change a secret, it can leak through that person. OWASP therefore calls for fine-grained, per-object access controls: engineers should not have access to all secrets, and generation can assign minimal privileges directly. In the cloud, strict IAM shrinks the blast radius.

Secret Scanning (Detection)

Secret detection finds secrets that have been checked in or exposed, either before or after they reach the repository. GitHub secret scanning recognizes known secret types in repositories; push protection blocks recognized secrets from being pushed in the first place. Open-source scanners such as Gitleaks or TruffleHog can be integrated into pre-commit hooks and pipelines.

Incident Response

Discovering a leaked secret requires a documented process: immediate rotation or revocation, checking the audit logs for misuse, and fixing the root cause. Short rotation intervals and dynamic secrets limit the window during which a stolen secret is usable at all.

Sources

Keep reading
AttackAPI Secrets & Key Leakage FundamentalsAPI Authentication OWASP API8Security Misconfiguration