PATTERN Cited by 1 source

Dynamic allowlist for safe exposure

Shape

Maintain a runtime-configurable allowlist of (endpoint, field/identifier, context) tuples where sensitive data exposure is intentional and safe, so the detection pipeline can suppress findings for those tuples without redeploy and without globally disabling the check.

Essential companion to any continuous-detection system: without it, the true-positive-drowning alert volume destroys engineer trust; with it, the alerts stay signal-dense.

Why this is necessary

Not every appearance of sensitive data in a response is a bug. From Figma's post (Source: sources/2026-04-21-figma-visibility-at-scale-sensitive-data-exposure):

"An OAuth client secret might be intentionally returned from a dedicated credential management endpoint for authorized users, but would be a serious issue if included in unrelated API responses."

A static "never return this field" rule over-fires. A static "always allow this endpoint" rule over-permits. The correct unit of allowlisting is a context-bound combination: this value, in this endpoint, for this role.

Design properties

1. Runtime-configurable (no redeploy). Dynamic configuration lets the team adjust without shipping code — critical during incident response when a flood of false positives is masking a real finding.
2. Narrowly scoped. Each entry pins down (endpoint | field | optional-role | optional-value-shape). Avoid blanket entries that drift into under-detection.
3. Auditable. Every allowlist entry should have a justification field, an owner, and ideally an expiry date. This is a security control disguised as a config file.
4. Visible in triage. When a finding is suppressed, the triage tool should show that it matched an allowlist entry so engineers can spot if an entry became overly broad.
5. Periodically reviewed. Like concepts/least-privileged-access grants, allowlist entries tend to accumulate cruft. Quarterly review + purging stale entries keeps the surface lean.

Contrast with adjacent allowlist patterns

• patterns/data-driven-allowlist-monitoring-mode — build the initial allowlist from observed passive-mode traffic before flipping to enforcement. Complementary: the initial build vs ongoing maintenance.
• patterns/static-allowlist-for-critical-rules — a code-committed allowlist for critical infrastructure tools that must never be blocked. Appropriate when stability matters more than flexibility; opposite axis.

This pattern (dynamic for safe-exposure) is the right choice when:

• New legitimate exposures are discovered regularly (new endpoints, new product features).
• Incident triage needs rapid "suppress this specific finding" capability.
• Entries are context-specific rather than broad.

Failure modes

• Catch-all entries. A single "suppress * for endpoint X" entry opens the door for any future bug in endpoint X to be silently suppressed. Enforce scoping.
• Forgotten entries. A temporary allowlist added during incident response never gets removed. Ownership + expiry save the day.
• Entry created to hide a real bug. Treat every allowlist addition as a security-sensitive change — require review, not just merge.
• Blind allowlist coverage. If triage tooling doesn't show suppressions, allowlist mistakes become invisible. Always expose suppression activity to the reviewing human.

Implementation hints

• Represent as versioned JSON / YAML in a central config store, not in-code constants — so runtime reload is possible.
• Hash the allowlist shape (endpoint, field, value-pattern) for fast O(1) lookup during sampling.
• Log suppressed findings at a lower severity so rare drift is still audit-visible without alerting on it.
• Require PR review with a security owner for any new entry.

Seen in

• sources/2026-04-21-figma-visibility-at-scale-sensitive-data-exposure — Figma's Sensitive Data Analyzer uses a flexible allowlisting process for endpoints with intentional, safe exposure (OAuth client-secret endpoint named as canonical example).