docs(sensitive-data): Overhaul docs around HTTP headers #15616
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
|
|
||
| - HTTP Headers: The keys of known sensitive headers (such as `Authorization` or `Cookie`) are added, while their values must be replaced with `"[Filtered]"`. | ||
|
|
||
| <Expandable title="List of sensitive HTTP headers"> |
There was a problem hiding this comment.
Let’s show all content instead.
|
|
||
| The SDK performs a **partial, case-insensitive match** against the following headers to determine if they are sensitive: | ||
|
|
||
| `['auth', 'token', 'secret', 'cookie', '-user', 'password', 'key', 'jwt', 'bearer', 'sso', 'saml']` |
There was a problem hiding this comment.
As the strings are partially matched, user-agent would also match if it is just user. -user would match e.g. x-user.
| and is **disabled by default**. That means that data that is naturally sensitive is not sent by default. | ||
|
|
||
| Some examples of data guarded by this flag: | ||
| Handling sensitive data in the SDK regardless of the `send_default_pii` setting: |
There was a problem hiding this comment.
| Handling sensitive data in the SDK regardless of the `send_default_pii` setting: | |
| Certain sensitive data must never been sent by the SDK, regardless of any config: |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| Certain sensitive data must never been sent by the SDK, regardless of any config: | ||
|
|
||
| - HTTP Headers: The keys of known sensitive headers are added, while their values must be replaced with `"[Filtered]"`. | ||
| - The SDK performs a **partial, case-insensitive match** against the following headers to determine if they are sensitive: `["auth", "token", "secret", "password", "passwd", "key", "jwt", "bearer", "sso", "saml", "crsf", "xsrf", "credentials"]` |
There was a problem hiding this comment.
Bug: CSRF misspelled as CRSF in sensitive header list
The sensitive header matching list includes "crsf" instead of "csrf". Since SDKs perform partial case-insensitive matching against this list to filter sensitive headers, the misspelling means headers containing csrf won't be detected and filtered. This allows CSRF tokens to be sent unfiltered to Sentry, exposing sensitive security credentials that should always be replaced with "[Filtered]".
|
|
||
| - HTTP Headers: The keys of known sensitive headers (such as `Authorization` or `Cookie`) are added, while their values must be replaced with `"[Filtered]"`. | ||
| - HTTP Headers: The keys of known sensitive headers are added, while their values must be replaced with `"[Filtered]"`. | ||
| - The SDK performs a **partial, case-insensitive match** against the following headers to determine if they are sensitive: `["auth", "token", "secret", "password", "passwd", "key", "jwt", "bearer", "sso", "saml", "crsf", "xsrf", "credentials"]` |
There was a problem hiding this comment.
| - The SDK performs a **partial, case-insensitive match** against the following headers to determine if they are sensitive: `["auth", "token", "secret", "password", "passwd", "key", "jwt", "bearer", "sso", "saml", "crsf", "xsrf", "credentials"]` | |
| - The SDK performs a **partial, case-insensitive match** against the following headers to determine if they are sensitive: `["auth", "token", "secret", "password", "passwd", "key", "jwt", "bearer", "sso", "saml", "csrf", "xsrf", "credentials"]` |
Co-authored-by: Michi Hoffmann <[email protected]>
| Certain sensitive data must never been sent by the SDK, regardless of any configuration: | ||
|
|
||
| - HTTP Headers: The keys of known sensitive headers are added, while their values must be replaced with `"[Filtered]"`. | ||
| - The SDK performs a **partial, case-insensitive match** against the following headers to determine if they are sensitive: `["auth", "token", "secret", "password", "passwd", "pwd", "key", "jwt", "bearer", "sso", "saml", "crsf", "xsrf", "credentials"]` |
There was a problem hiding this comment.
Bug: Typo in sensitive header pattern list
The sensitive header pattern list contains "crsf" instead of "csrf". This typo prevents SDKs from properly filtering Cross-Site Request Forgery headers during partial case-insensitive matching, potentially allowing sensitive CSRF tokens to be sent to Sentry unfiltered.
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
|
|
||
| SDKs should only replace sensitive data with `"[Filtered]"` when the data is gathered automatically through instrumentation. | ||
| If a user explicitly provides data (for example, by setting a request object on the scope), the SDK must not modify it. | ||
|
|
||
| Some examples of data guarded by `send_default_pii: false`: | ||
|
|
||
| - When attaching data of HTTP requests and/or responses to events | ||
| - Request Body: "raw" HTTP bodies (bodies which cannot be parsed as JSON or formdata) are removed | ||
| - HTTP Headers: known sensitive headers such as `Authorization` or `Cookie` are removed too. | ||
| - Request Body: "raw" HTTP bodies (bodies which cannot be parsed as JSON or FormData) are removed | ||
| - HTTP Headers: header values, containing information about the user are replaced with `"[Filtered]"` | ||
| - _Note_ that if a user explicitly sets a request on the scope, nothing is stripped from that request. The above rules only apply to integrations that come with the SDK. | ||
| - User-specific information (e.g. the current user ID according to the used web-framework) is not sent at all. | ||
| - User-specific information (e.g. the current user ID according to the used web-framework) is not collected and therefore not sent at all. |
There was a problem hiding this comment.
Bug: Contradictory guidance on HTTP header filtering leads to inconsistent SDK implementations.
Severity: CRITICAL | Confidence: High
🔍 Detailed Analysis
The documentation provides contradictory guidance on HTTP header filtering, specifically regarding the send_default_pii setting. Statement 1 (lines 16-19) mandates unconditional filtering for HTTP headers, while Statement 2 (lines 24-30) describes conditional filtering based on send_default_pii. Furthermore, Statement 3 (lines 44-57) treats cookies (which are HTTP headers) as conditionally filtered. This inconsistency will lead to divergent SDK implementations, where some SDKs might always filter headers, and others might filter them conditionally, resulting in inconsistent data handling across platforms.
💡 Suggested Fix
Clarify whether HTTP header filtering, including cookies, is always unconditional or if it depends on the send_default_pii setting. Ensure all related sections provide a unified and unambiguous rule.
🤖 Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: develop-docs/sdk/expected-features/data-handling.mdx#L16-L30
Potential issue: The documentation provides contradictory guidance on HTTP header
filtering, specifically regarding the `send_default_pii` setting. Statement 1 (lines
16-19) mandates unconditional filtering for HTTP headers, while Statement 2 (lines
24-30) describes conditional filtering based on `send_default_pii`. Furthermore,
Statement 3 (lines 44-57) treats cookies (which are HTTP headers) as conditionally
filtered. This inconsistency will lead to divergent SDK implementations, where some SDKs
might always filter headers, and others might filter them conditionally, resulting in
inconsistent data handling across platforms.
Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 3516138
DESCRIBE YOUR PR
Being more explicit about which HTTP headers we consider as sensitive and how SDKs should handle the data.
IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes: