Secure Use of Feature Flags and Toggles
🌟 Objective
To establish good practices for the secure use of feature flags (or toggles), with a focus on:
- Minimising the risk of failures in production;
- Enabling progressive and reversible deliveries;
- Reinforcing traceability, governance and formal validation;
- Preventing abuse or uncontrolled behaviour at runtime.
🧬 What Feature Flags are
Feature flags are mechanisms that make it possible to activate or deactivate functionality without a new deployment, based on configuration rules. They are widely used for:
- Progressive delivery;
- Canary releases;
- A/B testing;
- Failure containment;
- Operational management of critical functionality.
Common types of toggles
| Type | Description | Practical example |
|---|---|---|
| Release Toggle | Controls functionality under development | New API visible only to the internal team |
| Ops Toggle | Switches technical flows or sensitive integrations on/off | Temporarily deactivating the sending of emails |
| Permission Toggle | Defines who can access a functionality | Only admins access internal dashboards |
| Experiment Toggle | Supports experiments and optimisations by user group | Showing a new layout to 50% of users |
| Kill Switch | Deactivates functionality immediately | Interrupting notifications after an incident |
🛠️ How to apply
🔐 Security and isolation
- Never use toggles as a substitute for access control;
- Evaluate toggles in the backend - not only in the frontend;
- Avoid client-side toggles for sensitive logic;
- Ensure that all the associated logical paths are testable.
🛡️ Traceability and metadata
Each toggle must have:
- A unique and descriptive name;
- An owner (responsible team or person);
- A scope (environment, group, tenant, region...);
- An activation condition and an expiry condition;
- A functional and security justification.
📜 Management as code
- Manage toggles as infrastructure (e.g. Feature Flags as Code);
- Version the configuration (YAML, JSON, etc.);
- Apply via PRs, with review and formal approval.
🧪 Example of toggle metadata
toggle: enable_enhanced_logging
description: Ativa logging estendido para debugging
owner: equipa-devsecops
enabled_by_default: false
scope: ["staging", "grupo-beta"]
expires_after: 2025-12-01
justification: Necessário para investigação de comportamento anómalo
⚠️ Risks and bad practices
| Anti-pattern | Consequence |
|---|---|
| Toggle without an owner | Nobody knows who controls it |
| No expiry | Accumulated technical debt |
| Evaluation only in the frontend | Bypass possible through UI manipulation |
| Silent toggle (no logs) | Difficulty in debugging and auditing |
| No defined fallback | Unpredictable behaviour if switched off |
✅ Good practices
- Define a periodic review SLA (e.g. all toggles reviewed monthly);
- Alert on toggles active for more than 60 days;
- Block merges of code with toggles without metadata;
- Validate the alternative paths (with and without the toggle active);
- Include toggles in the release approval process.
🧰 Supporting tools
| Tool | Type | Notes |
|---|---|---|
| LaunchDarkly | SaaS | Dashboards, multi-language SDKs |
| Unleash | Open Source / SaaS | Self-hosted, rollout strategy |
| Flagsmith | SaaS / Open Source | Integration with GitOps and RBAC |
| FeatureHub | Open Source | Focus on multiple teams, multi-tenancy |
📎 Cross-references
| Document / Chapter | Relation to this topic |
|---|---|
| Ch. 01 - Risk Management | Risk assessment associated with toggles |
| Ch. 06 - Secure Development | Testability of conditional paths |
| Ch. 10 - Security Testing | A/B tests, induced failures and fallback |
| Ch. 11 - Secure Deployment | Toggles as an execution control mechanism |
| Ch. 12 - Monitoring and Operations | Active observation of behaviour with toggles |
🌟 Toggles are powerful - but only when used with discipline, control and traceability.
They must be treated as critical runtime assets, with direct implications for security and operational risk.