Safe Fields should support prefix/pattern matching, not just exact key names
Sentry's default data scrubbers trigger on substring regex patterns (auth, token, oauth, etc. anywhere in a field name), but Safe Fields only supports exact key name matches. This asymmetry makes it impractical to protect a namespace of categorical telemetry attributes from over-scrubbing.
Current behavior
- Default scrubbing uses a regex like
(?i)(auth|token|password|secret|...) matched as a substring against field names in Relay (relay-pii/src/regexes.rs).
- Safe Fields entries are converted to
SelectorSpec::Path with SelectorPathItem::Key, which compares with eq_ignore_ascii_case — exact match only (relay-pii/src/selector.rs).
- The selector syntax supports path wildcards (
*, **) but not substring glob matching within a key name (e.g., *oauth* is not valid and falls back to a literal key named *oauth*).
Gap
A project sending structured OAuth diagnostic telemetry (e.g. app.oauth.grant_revoked.reason, token-exchange outcome/status fields, client family, grant age bucket, upstream expiry bucket) cannot exempt those attributes as a group. These are categorical enum values — not bearer tokens or credentials — but every field whose name contains auth, oauth, or token gets redacted to [Filtered] because the trigger is substring-based.
To exempt them today, every field must be enumerated individually and exactly, with no path prefix or namespace shorthand. Any new attribute added to the namespace is silently scrubbed until manually added to the allowlist.
This makes Sentry materially harder to use for observing OAuth flows and other auth-adjacent subsystems in production, which is a real gap for projects doing LLM/MCP instrumentation and any first-party auth debugging.
Options
- Prefix matching: allow a trailing
* in Safe Fields entries so app.oauth.* exempts all keys under that prefix.
- Substring glob in key name: extend the selector grammar to support
*oauth* as a key-level glob, mirroring how sensitive-field triggers already work.
- Namespace exclusions: a separate "exclude namespace" input that protects all attributes under a given dot-separated prefix without requiring individual enumeration.
The minimal viable fix is prefix matching; it aligns with how users already reason about attribute namespaces.
Prior art
Safe Fields should support prefix/pattern matching, not just exact key names
Sentry's default data scrubbers trigger on substring regex patterns (
auth,token,oauth, etc. anywhere in a field name), but Safe Fields only supports exact key name matches. This asymmetry makes it impractical to protect a namespace of categorical telemetry attributes from over-scrubbing.Current behavior
(?i)(auth|token|password|secret|...)matched as a substring against field names in Relay (relay-pii/src/regexes.rs).SelectorSpec::PathwithSelectorPathItem::Key, which compares witheq_ignore_ascii_case— exact match only (relay-pii/src/selector.rs).*,**) but not substring glob matching within a key name (e.g.,*oauth*is not valid and falls back to a literal key named*oauth*).Gap
A project sending structured OAuth diagnostic telemetry (e.g.
app.oauth.grant_revoked.reason, token-exchange outcome/status fields, client family, grant age bucket, upstream expiry bucket) cannot exempt those attributes as a group. These are categorical enum values — not bearer tokens or credentials — but every field whose name containsauth,oauth, ortokengets redacted to[Filtered]because the trigger is substring-based.To exempt them today, every field must be enumerated individually and exactly, with no path prefix or namespace shorthand. Any new attribute added to the namespace is silently scrubbed until manually added to the allowlist.
This makes Sentry materially harder to use for observing OAuth flows and other auth-adjacent subsystems in production, which is a real gap for projects doing LLM/MCP instrumentation and any first-party auth debugging.
Options
*in Safe Fields entries soapp.oauth.*exempts all keys under that prefix.*oauth*as a key-level glob, mirroring how sensitive-field triggers already work.The minimal viable fix is prefix matching; it aligns with how users already reason about attribute namespaces.
Prior art