How to Manage Secrets and API Keys Securely

Secrets, in the context of a web application, are any piece of information that grants access to a system or service and must not be made public. This includes database passwords, API keys for third-party services, OAuth client secrets, private encryption keys and credentials for cloud infrastructure. An API key is a specific type of secret: a token issued by an external service — a payment gateway, an email delivery platform, a mapping provider — that identifies your application and controls what it is allowed to do.

Decision summary: Inventory every secret, remove it from code and logs, minimise scope, automate safe rotation and retain evidence of access and revocation.

The core problem is straightforward: if a secret ends up in the wrong hands, someone can access your data, make charges against your accounts, impersonate your application or reach into your infrastructure. The risk is not theoretical. Public source-code repositories are routinely scanned by automated tools that extract committed keys within minutes of them appearing.

The fundamental principle is that secrets must never live inside your application's source code. Source code gets committed to repositories, shared across development machines, copied to staging environments and reviewed by multiple people. Once a secret is baked into a commit history, removing it from the current file does not remove it from the record. The correct approach is to keep secrets entirely separate from code and inject them into the application at runtime through a controlled mechanism.

Environment variables are the most basic form of this separation. The application reads a value like DATABASE_PASSWORD from its surrounding environment rather than from a configuration file in the codebase. This works, but it has practical limitations: environment variables are often stored in plain text on the server, they can be exposed through process listings or debugging endpoints, and they are difficult to rotate, audit and share across multiple services without creating copies that drift out of sync.

Dedicated secret management tools — services that store, encrypt and distribute secrets on demand — address these limitations. They provide access logging, automatic rotation, fine-grained permissions and integration with deployment pipelines. For a business system that handles customer data or connects to payment services, this is the standard you should expect your supplier to meet.

A proportionate security baseline

For “How to Manage Secrets and API Keys Securely”, security controls should be selected from a documented risk assessment and tested in the complete service. No single product, certificate or test removes the need for secure design, access control, monitoring, patching, incident response and recoverable backups.

Where secrets appear in a typical business system

Most non-trivial web applications depend on external services, and each connection requires a credential. A CRM might hold keys for an email delivery service, a payment processor, an accounting package and a cloud storage bucket. An internal portal might need database credentials, an LDAP or Active Directory secret for authentication, and API keys for any number of back-office integrations. SaaS products typically add OAuth client secrets, webhook signing keys and sometimes tenant-specific credentials that vary per customer.

Understanding where secrets exist is the first step. A useful exercise is to ask your team or supplier to produce a complete register of every external dependency and the credential type it requires. Gaps in this register are where problems start.

Handling secrets across environments

Development, staging and production environments should each use different credentials. A developer working locally should never use the production database password, and a staging environment should connect to its own payment-sandbox keys rather than live ones. When environments share secrets, a mistake in one place immediately threatens another.

This separation creates a management burden: each environment needs its own set of values, each set needs to be stored and accessed securely, and deployment tooling needs to inject the correct values for the target environment without human intervention. This is precisely what secret management tools and infrastructure-as-code practices are designed to handle.

Rotation and revocation

Keys should have a defined lifecycle. Some services support automatic rotation, where a new key is generated and the old one is retired on a schedule. Where automatic rotation is not available, you need a manual process: generate a new key, update the secret store, redeploy the application, confirm it is working with the new key, then revoke the old one. The gap between generating the new key and revoking the old one should be as short as possible.

Revocation is equally important when a team member leaves, when a supplier relationship ends or when a key is suspected of being exposed. If you cannot revoke a key independently of the entire service, that is a limitation worth knowing about before you commit to that service.

Questions to put to a supplier or development team

• Where are secrets stored, and who has access to that storage?
• Are secrets ever committed to the source-code repository, even in historical commits?
• How are secrets injected into the application at each stage — local development, CI/CD pipeline, staging and production?
• Is there a secret management tool in place, and if so, which one?
• What is the process for rotating a key, and how long does it take?
• Can access to secrets be audited — is there a log of who retrieved what and when?
• What happens if a key is accidentally pushed to a public repository?

Committing secrets to source control

This remains the single most common cause of secret exposure. A developer adds a key to a configuration file, commits it, and the file sits in the repository history indefinitely. Even if the key is removed in a subsequent commit, anyone with repository access can retrieve it from the earlier version. Pre-commit hooks and repository scanning tools can catch these mistakes, but they are not a substitute for keeping secrets out of code entirely.

Sharing secrets through informal channels

Slack messages, emails and shared documents are not secure storage for credentials. They persist indefinitely, they can be forwarded, they sit in backups and they are searchable. Once a secret has been shared this way, you have no reliable way to confirm who has seen it or whether it has been copied further. The correct path is to use the secret management tool's built-in sharing and access-granting features, which are designed to be auditable and revocable.

Treating API keys as low-risk

There is a persistent assumption that because an API key is not a password, it is less sensitive. In reality, an API key for a payment service can be used to initiate transactions. A key for a cloud storage service can be used to download or delete data. A key for an email service can be used to send messages from your domain. The sensitivity of a key is determined by what it grants access to, not by its format.

Limitations of environment variables

Environment variables are better than hardcoding, but they are not a complete solution. On a shared server, one process can sometimes read another's environment. Debugging tools and error pages can inadvertently expose environment values. There is no built-in audit trail showing who read a variable or when. And when an application scales to multiple services, each needing overlapping sets of secrets, environment variables become difficult to manage without duplication. If your supplier relies solely on environment variables, ask what happens when the system grows beyond a single server.

Key checks before accepting a system

• Confirm that no secrets appear in the delivered source code, including in configuration files, test fixtures or commented-out lines.
• Verify that the repository history has been checked for previously committed secrets and that any found have been rotated.
• Ensure that production secrets are not accessible from development or staging environments.
• Check that there is a documented process for adding, rotating and revoking each type of secret.
• Confirm that access to the secret store is restricted to the minimum number of people and services.
• Ask whether the CI/CD pipeline has access only to the secrets it genuinely needs, rather than a blanket set of all credentials.
• Verify that secrets are not logged in application output, error reports or monitoring dashboards.

Secret management is not a feature to add later. The decisions about where credentials live, who can reach them and how they are rotated are structural choices that become significantly harder to change once a system is in production. Raising these points during discovery or supplier evaluation, rather than after a security incident, is the practical next step.

Security evidence to require

• Define the protected asset, likely abuse case and evidence that the control still works in production.
• Define the assets, threats, trust boundaries and business impact before selecting controls.
• Give named owners responsibility for patching, access reviews, logging, incident response and recovery testing.
• Prefer phishing-resistant authentication where practical and document recovery paths with the same care as login.

Primary guidance checked for this edition

Sources for “How to Manage Secrets and API Keys Securely” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.

• NCSC: Identity and access management
• NCSC: Vulnerability management
• NCSC: Planning cyber-incident response