The problem with named values for secrets
In our work, we help organisations build secure and scalable integration platforms on Azure. One of the most common—and risky—missteps we encounter is the use of named values in Azure API Management (APIM) to store secrets.
It’s a pattern that seems convenient at first. But when multiple development teams share the same APIM instance, this practice can quickly become a security liability.
Named values in APIM are often used to store configuration data like URLs, keys, or tokens. While they support encryption, they’re not designed to be a secure secrets store. Here’s why that matters:
- Access Scope: Named values can be accessed by any policy in the APIM instance. If multiple teams are deploying APIs, it’s easy to unintentionally expose secrets across boundaries.
- Auditability: There’s limited visibility into who accessed or modified a named value—making it hard to track misuse or unauthorised changes.
- Lifecycle Management: Named values don’t support versioning, expiry, or rotation policies like Azure Key Vault does.
- Least Privilege Violations: Developers may gain access to secrets they don’t need, violating the principle of minimal access.
In short, storing secrets in named values is like leaving your house key under the doormat—technically hidden, but not really secure.
Why Azure Key Vault is the right place
As outlined in our own internal architecture guidelines, we always recommend using Azure Key Vault for managing secrets. It provides:
- Centralised, secure storage for tokens, passwords, and certificates.
- Fine-grained access control via Azure RBAC and managed identities.
- Built-in support for secret rotation and auditing
This approach ensures that secrets are protected, traceable, and managed according to best practices—especially in environments with multiple teams and shared infrastructure.
How Helium Helps Us Enforce This
To support this standard, we use Helium to automatically scan APIM instances and flag any named values that appear to contain secrets. For example, in a recent scan of a shared development environment, Helium flagged the following:
This proactive alert allowed our integration support engineers to:
- Identify and review the named value.
- Migrate the secret to Azure Key Vault.
By integrating Helium into our delivery and support model, we ensure that security isn’t just a checklist—it’s a continuous, automated process.
Why this matters for our clients
When multiple teams share the same APIM instance, governance becomes critical. Helium helps us:
- Detect risky configurations early.
- Enforce consistent security standards across teams.
- Reduce the risk of accidental exposure or privilege escalation.
It’s one of the many ways we help our clients build integration platforms that are not only functional—but secure by design.
