Skip to content

Commit 95fa29b

Browse files
aadelbkingthorin
aadelb
authored and
kingthorin
committed
feat(WSTG-CONF-15): add testing for feature flag security bypass
Add new test case for security testing of feature flag implementations. This test case addresses the security gaps in modern applications that use feature flags and progressive delivery techniques. It covers: - Client-side flag manipulation attacks - Authorization bypass via hidden endpoints - Information leakage in flag configurations - Fail-open fallback behavior testing - Stale feature flag vulnerabilities Test ID: WSTG-CONF-15 Fixes #1265
1 parent 9b26307 commit 95fa29b

2 files changed

Lines changed: 192 additions & 0 deletions

File tree

‎document/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/15-Test_for_Feature_Flag_Security_Bypass.md‎

Lines changed: 190 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,190 @@
1+
# Testing for Feature Flag Security Bypass
2+
3+
|ID |
4+
|------------|
5+
|WSTG-CONF-15|
6+
7+
## Summary
8+
9+
Feature flags (also known as feature toggles, feature switches, or feature gates) are a software development technique that allows teams to enable or disable functionality without deploying new code. While feature flags provide significant benefits for progressive delivery and A/B testing, they can introduce security vulnerabilities when improperly implemented.
10+
11+
Common security issues with feature flags include:
12+
13+
- **Client-side manipulation**: Flags evaluated in the browser can be modified by attackers to enable restricted features.
14+
- **Authorization bypass**: Hidden UI elements may still have accessible back-end endpoints.
15+
- **Information disclosure**: Flag configurations may leak unreleased features or internal logic.
16+
- **Insecure defaults**: Fallback values when the flag service is unavailable may fail open.
17+
- **Stale flag vulnerabilities**: Unused flags referencing deprecated code paths may contain unpatched vulnerabilities.
18+
19+
Modern applications increasingly rely on feature flag services (LaunchDarkly, Split, Flagsmith, ConfigCat) or custom implementations for controlled rollouts, making security testing of these mechanisms essential.
20+
21+
## Test Objectives
22+
23+
- Identify feature flags that gate security-relevant functionality.
24+
- Assess whether feature flag states can be manipulated client-side.
25+
- Verify that back-end authorization is independent of flag state.
26+
- Determine if flag configurations expose sensitive information.
27+
- Evaluate fail-safe behavior when the flag service is unavailable.
28+
29+
## How to Test
30+
31+
### Identify Feature Flags in the Application
32+
33+
Search for evidence of feature flag implementations:
34+
35+
1. **Inspect JavaScript bundles** for references to feature flag services or configuration objects:
36+
37+
```javascript
38+
// Common patterns to search for:
39+
featureFlags
40+
featureToggles
41+
flags.isEnabled
42+
LaunchDarkly
43+
splitio
44+
flagsmith
45+
```
46+
47+
2. **Monitor network traffic** for requests to feature flag endpoints:
48+
49+
```http
50+
GET /api/features HTTP/1.1
51+
Host: example.com
52+
53+
HTTP/1.1 200 OK
54+
Content-Type: application/json
55+
56+
{
57+
"features": {
58+
"new_checkout_flow": true,
59+
"admin_panel_v2": false,
60+
"beta_api": false
61+
}
62+
}
63+
```
64+
65+
3. **Examine local storage and cookies** for cached flag values.
66+
67+
### Test Client-Side Flag Manipulation
68+
69+
Attempt to modify flag values to enable restricted features:
70+
71+
1. **Intercept and modify responses**: Use a proxy tool to change flag values from `false` to `true` in API responses.
72+
73+
```http
74+
# Original response
75+
{"admin_mode": false}
76+
77+
# Modified response
78+
{"admin_mode": true}
79+
```
80+
81+
2. **Modify local storage**: If flags are cached client-side, change the values directly.
82+
83+
```javascript
84+
// In browser console
85+
localStorage.setItem('featureFlags', JSON.stringify({
86+
...JSON.parse(localStorage.getItem('featureFlags')),
87+
restricted_feature: true
88+
}));
89+
```
90+
91+
3. **Observe application behavior**: Determine if the application grants access to functionality that should be restricted.
92+
93+
### Verify Backend Authorization Independence
94+
95+
Ensure back-end endpoints enforce authorization independently of flag state:
96+
97+
1. **Identify hidden endpoints**: Extract API endpoints from JavaScript bundles that are associated with disabled features.
98+
99+
```bash
100+
# Search for API patterns in JS files
101+
grep -oE '/api/v[0-9]+/[a-zA-Z_]+' bundle.js
102+
```
103+
104+
2. **Send direct requests**: Attempt to access endpoints for disabled features.
105+
106+
```http
107+
POST /api/admin/users/delete HTTP/1.1
108+
Host: example.com
109+
Authorization: Bearer <user_token>
110+
Content-Type: application/json
111+
112+
{"user_id": "12345"}
113+
```
114+
115+
3. **Expected result**: The server should return `403 Forbidden` if the feature is disabled, not just hide the UI.
116+
117+
### Test Fallback Behavior
118+
119+
Evaluate what happens when the feature flag service is unavailable:
120+
121+
1. **Block connectivity** to the flag provider using browser DevTools network blocking or hosts file modification.
122+
123+
```bash
124+
# Add to /etc/hosts (testing only)
125+
127.0.0.1 sdk.launchdarkly.com
126+
127.0.0.1 app.split.io
127+
```
128+
129+
2. **Observe fallback behavior**: Determine if the application fails open (enables features) or fails closed (disables features).
130+
131+
3. **Security-critical result**: Features gating security controls should default to disabled when the flag service is unreachable.
132+
133+
### Analyze Flag Configuration for Information Leakage
134+
135+
Examine flag payloads for sensitive information:
136+
137+
1. **Capture flag configuration responses** and look for:
138+
- Unreleased feature names revealing roadmap
139+
- Internal tool references
140+
- Targeting rules containing email domains or user identifiers
141+
- Environment-specific configurations
142+
143+
2. **Example of information leakage**:
144+
145+
```json
146+
{
147+
"flags": {
148+
"internal_admin_tool_q1_2025": false,
149+
"bypass_rate_limit_for_enterprise": false,
150+
"show_feature_if_email_contains_@internal.company.com": true
151+
}
152+
}
153+
```
154+
155+
### Test for Stale Feature Flags
156+
157+
Identify and test unused flags that may expose deprecated functionality:
158+
159+
1. **Map all flags** and their creation dates if available.
160+
2. **Force-enable old flags** and observe if deprecated code paths are accessible.
161+
3. **Assess deprecated code** for known vulnerabilities or security weaknesses.
162+
163+
## Remediation
164+
165+
To prevent feature flag security bypass vulnerabilities:
166+
167+
- **Server-side evaluation**: Evaluate security-critical flags on the server, never trust client-provided values.
168+
- **Authorization independence**: Backend authorization checks must not depend on flag state.
169+
- **Fail-secure defaults**: Configure security-relevant flags to default to disabled if the flag service fails.
170+
- **Minimal client exposure**: Only send flag evaluation results to clients, not targeting rules or full configurations.
171+
- **Flag hygiene**: Implement policies to remove flags after their purpose is complete (typically 30-90 days post-launch).
172+
- **Audit logging**: Log flag evaluations for security-critical features.
173+
174+
For more details, see:
175+
176+
- [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/)
177+
- [OWASP Top Ten - A01:2021 Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/)
178+
179+
## Tools
180+
181+
- [Burp Suite](https://portswigger.net/burp) - Intercept and modify HTTP traffic
182+
- [OWASP ZAP](https://www.zaproxy.org/) - Web application security testing
183+
- Browser Developer Tools - Network inspection and local storage modification
184+
185+
## References
186+
187+
- [Feature Toggles (aka Feature Flags) - Martin Fowler](https://martinfowler.com/articles/feature-toggles.html)
188+
- [LaunchDarkly Security Best Practices](https://docs.launchdarkly.com/home/security)
189+
- [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)
190+

‎document/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README.md‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,3 +27,5 @@
2727
4.2.13 [Test for Path Confusion](13-Test_for_Path_Confusion.md)
2828

2929
4.2.14 [Test for Other HTTP Security Header Misconfigurations](14-Test_Other_HTTP_Security_Header_Misconfigurations.md)
30+
31+
4.2.15 [Test for Feature Flag Security Bypass](15-Test_for_Feature_Flag_Security_Bypass.md)

0 commit comments

Comments
 (0)