Feature Flag Security: control who can change production behaviour and prove it

A feature flag platform lets someone change how production behaves in seconds, without a commit, a pipeline run or a change ticket, and in many organisations that path is less controlled than the deployment pipeline it was meant to complement. Flags gate unreleased features, run experiments, act as kill switches during incidents and, in some products, decide which customers can use which capability. That makes the flag console, its API tokens and the SDK keys embedded in applications part of your production change path and, sometimes, part of your access control. This guide covers the platform as a security asset: SDK key types, admin roles, approval for production flag changes, audit logging, targeting data, flags that must never act as security controls, and flag retirement. It is vendor-neutral and written for platform engineers, application security teams and change managers. Release gates in general are covered in Release Management Security Gates, and the wider change process in Change Management Security.

Key takeaways

• A flag change is a production change. Treat flipping a production flag like a deployment: named people, role-based access, approval for flags that touch security or money, and an audit trail you keep.
• Know which keys are public. Keys shipped in browser and mobile apps can be read by anyone, so they must only allow flag evaluation; server-side SDK keys and management API tokens are real secrets.
• Never let a flag be the only security control. Authorisation must be enforced at a trusted service layer, not by a flag value a client can see or influence.
• Targeting rules carry data. User attributes sent for targeting, and rules sent to clients, can expose personal data and unreleased plans.
• Flags are inventory with a carrying cost. Give every flag an owner, a type and an expiry, and remove the code path when it is done.

Why the flag platform is a production change path

The OpenFeature specification, a Cloud Native Computing Foundation incubating project, defines a feature flag as a mechanism that lets an application author define alternative code paths within deployed software, and a flag management system as the source of truth for flag values and rules. Both code paths are already in production. The flag system decides which one runs, for whom, and when.

Pete Hodgson's widely cited article on martinfowler.com groups flags into four categories. Each carries a different risk, so the controls should differ by type.

The categories and life spans come from the Hodgson article; the controls column is NHI Mgmt Group's recommendation. Permissioning flags deserve the most attention: once a flag decides who may use a paid tier, an admin feature or a data export, changing it is an access change.

SDK keys, client IDs and management tokens

Flag platforms commonly issue several kinds of credential. Names differ between products, so map your platform's own credential names onto these classes and confirm the exact scope of each in the vendor's current documentation.

• Server keys hold the whole rule set: a server-side SDK typically downloads every rule and segment for its environment so it can evaluate locally. Anyone holding the key can read targeting rules, segment membership lists and unreleased flag names. Store it in a secrets manager (OWASP ASVS V13.3.1), never in front-end code or a public repository.
• Separate keys per environment: a development key must not read production rules. Use one key per environment per service where the platform allows, so revocation is targeted.
• Scope management tokens: give automation tokens only the projects, environments and actions they need, with an expiry. A token that can change production flags is equivalent to deploy rights.
• Rotate on exposure: rotate server keys and management tokens when a person leaves, when a key appears in a log or repository, and on a schedule. NHI Mgmt Group recommends 90 days or less for management tokens and pairing rotation with a dual-key overlap so services do not fail. See the Secrets Rotation Runbook Template.
• Mark client-visible flags deliberately: only flags explicitly made available to client-side SDKs should be readable with a client key. A flag named after an unannounced product or an internal security change tells an attacker what is coming.

Admin roles and approval for production flags

Flag consoles are often opened to product managers, support staff and engineers so they can move quickly. That is reasonable for non-production environments. In production, the same principles as any change control apply: least privilege (NIST SP 800-53 AC-6), access restrictions for change (CM-5) and separation of duties (AC-5).

1. Sign in through your identity provider: single sign-on with MFA for every console user, and automatic deprovisioning through SCIM or group sync. Local console accounts outside SSO are the first thing to remove.
2. Define roles by environment: broad edit rights in development and staging; in production, a small group of flag maintainers, a read-only role for everyone else, and a separate role for managing members, keys and integrations.
3. Tag high-risk flags: mark flags that touch authentication, authorisation, payments, data export, rate limits, logging or security controls. Our recommendation is that these require a second person to approve a production change, using the platform's approval workflow if it has one, or by managing those flags only as code with pull request review.
4. Pre-approve kill switches: incident responders need to act fast. Document which ops flags may be changed without approval, by whom, and require a post-incident record within one working day (our recommendation).
5. Manage flags as code where it fits: Hodgson notes that keeping flag configuration in source control lets it move through the delivery pipeline with the code and records past states. Infrastructure as code for flag definitions, environments and roles gives you review and history for free; keep console edits for the dynamic cases.
6. Review access quarterly: list who holds production edit rights, admin rights and active API tokens, and remove anyone who has not changed a flag in the review period.

Audit logging and detection

The OWASP Logging Cheat Sheet lists configuration changes, use of administrative privileges and user administration among the events to always log, with when, where, who and what recorded for each. OWASP ASVS V16.2.1 asks for the same metadata. For a flag platform, that means every change to a flag, rule, segment, environment, member, role, key or integration.

• Export the audit log: retention inside a SaaS console may be shorter than your audit and investigation needs. Stream it to your SIEM or log store where flag administrators cannot alter it (AU-9; ASVS V16.4.2).
• Use evaluation hooks for runtime evidence: the OpenFeature hooks section (status: hardening) describes before, after, error and finally stages and lists telemetry and logging among the uses. A hook can record which flag variant served a request, which helps link an incident to a flag change. Do not write evaluation context containing personal data into these logs.
• Correlate with incidents: when error rates or fraud signals jump, the first question should be "did a flag change?". Put flag change events on the same timeline as deployments.

Flags that must not act as security controls

OWASP ASVS V8.3.1 requires authorisation rules to be enforced at a trusted service layer, not by controls an untrusted consumer could manipulate. A flag evaluated in the browser or a mobile app is exactly that kind of control: the user can read the variant, change it in memory or call the API the hidden button would have called.

• Hiding is not protecting: a client-side flag that hides an admin menu does nothing if the admin API does not check permissions itself. Enforce every permission on the server, then use the flag only to shape the interface.
• Do not gate security fixes behind default-off flags for long: a fix shipped "off" leaves the vulnerable path live. Turn it on quickly and remove the old path.
• Fail safe on evaluation errors: decide what the default variant is when the platform is unreachable. For security-relevant flags the default should be the safer behaviour, for example "check enforced" rather than "check skipped".
• Do not use flags to toggle logging or authentication off in production without the same approval as any other security control change. A flag that silences audit logs is an attractive target.
• Do not trust context sent by clients: if a server evaluates a flag using attributes supplied by the client (plan, role, country), a user can change them. Derive security-relevant attributes from the authenticated session on the server.

Targeting data and privacy

The OpenFeature glossary describes the evaluation context as the information used for flag evaluation and the targeting key as the identifier for the subject of evaluation, which may be an end user or a service. Teams tend to add attributes over time: email address, account name, IP address, plan, internal role. Some platforms store these attributes or send them back for analytics.

• Minimise: use an opaque, stable identifier as the targeting key rather than an email address, and pass only the attributes the rules need.
• Classify the platform: if personal data reaches the flag vendor, record it in your data inventory and supplier assessments like any other processor (OWASP ASVS V14.1.1 asks for sensitive data to be identified and classified).
• Watch client-side rule leakage: where rules or segment lists are evaluated on the client, the client may receive more than its own result. Prefer server-side evaluation for segments that list customers or staff.
• Keep secrets out of variants: flag values are configuration, not a secrets store. A variant holding an API key or a connection string is readable by every SDK key holder. Keep secrets in the secrets manager; see the Secrets Management Guide.

Where identity fits

Most flag platform credentials are non-human identities: server SDK keys in dozens of services, management tokens in pipelines, relay credentials and integration secrets. They are rarely in the identity inventory, are often shared across services, and seldom rotate. Add them to your NHI inventory with an owner, environment and scope, and use short-lived or workload-federated credentials for automation where the platform supports them. The general model is in the API Key Management Guide.

Rolling out controls on an existing flag estate

1. Inventory (weeks 1 to 2): export every flag with environment, type, owner, last change and age; list every member, role, SDK key and API token. Search code and repositories for server keys and tokens.
2. Quick fixes (weeks 2 to 4): enforce SSO and MFA, remove dormant members, rotate any key found in code or logs, and start exporting the audit log.
3. Classify flags: tag release, experiment, ops and permissioning flags, and mark high-risk ones. Start with production.
4. Pilot approvals: turn on approval for high-risk flags in one product team first. Measure how often approvals delay incident work, and adjust the kill switch exemptions before widening.
5. Widen and automate: extend approvals, move stable flags into infrastructure as code, and add expiry checks to CI so builds warn on flags past their removal date.
6. Rollback: if approvals block an incident, use the documented break-glass role (logged and alerted) rather than disabling the workflow for everyone.

Small organisations can stop at SSO, two production roles, exported logs and a monthly flag clean-up. Large organisations with many teams benefit from flags as code, approval workflows and automated expiry enforcement.

Measuring it

• Production flag changes with an identified approver or linked ticket: target close to 100% for high-risk flags.
• Flags past their expiry date: count and trend; Hodgson suggests expiry dates and limits on active flags as ways to keep toggle debt low.
• Users with production edit rights: number and change over time.
• SDK keys and API tokens older than the rotation target: count, aiming for zero.
• Security-relevant flags evaluated only on the client: should be zero.

Common failure patterns

• Everyone is a production editor: console access granted for convenience during a launch and never removed.
• Server SDK key in the front end: a server key bundled into JavaScript exposes the entire rule set and segment lists.
• Permissioning by client flag: admin features hidden by a flag but the API does not check roles.
• Audit trail lost: the console keeps changes for a short period and nobody exported them, so a suspicious change months ago cannot be traced.
• Zombie flags: release flags left in code for years, with both paths still live and the old path unpatched.
• Management token in a public repository: long-lived tokens leak like any other secret; scan for them. The pattern in the Toyota T-Connect key exposure (an access key in source code on public GitHub for almost five years) applies to flag tokens too.

Framework mapping

Practitioner checklist

• Inventory every flag, member, role, SDK key and API token, by environment.
• Enforce SSO with MFA and automatic deprovisioning for the flag console.
• Restrict production edit rights to named maintainers; separate member and key administration.
• Tag high-risk flags and require a second approver or code review for their production changes.
• Store server SDK keys and management tokens in a secrets manager; scope and rotate them.
• Expose only deliberately chosen flags to client-side keys.
• Enforce authorisation on the server; never rely on a client-evaluated flag for access.
• Export the platform audit log to a store administrators cannot alter, and alert on high-risk changes.
• Minimise targeting attributes and record the platform in your data inventory.
• Set an owner and expiry on every flag and remove finished flags from code.

Standards and references

• OpenFeature: Specification
• OpenFeature: Specification glossary
• OpenFeature: Hooks
• martinfowler.com (Pete Hodgson): Feature Toggles (aka Feature Flags)
• OWASP: Logging Cheat Sheet
• OWASP: Application Security Verification Standard 5.0
• NIST: SP 800-53 Rev 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Release Management Security Gates · Change Management Security · API Key Management Guide · Secrets Management Guide