SQL span integrations shouldn't include values in span descriptions to avoid PII

[bruno-garcia]

If we just take the raw SQL (or ORMs such as AndroidX Room, Apple Core Data, .NET EF) and add to Sentry events. In the form of crumbs or spans, it can leak PII

We need to have some guidelines for SDK engineers. Similar to the HTTP one on the develop docs. There we can point out possible pitfalls and what's suggested in such cases.

• https://github.com/getsentry/sentry-android-gradle-plugin/issues/349
• https://github.com/getsentry/sentry-cocoa/issues/1972

Some open questions:

• Could we add the values if sendDefaultPii is true?
• Can we send the values in the data bag? Perhaps also only behind the sendDefaultPii?
• What do we do if the integration doesn't have access to the query before values are already interpolated (we only receive the final query). Do we try to regex on the client?
• Do we have PII stripping server side for Span data?
• Document how to do PII stripping of transactions spans and crumbs. beforeBreadcrumb? For transactions do we require an event processor or is there a hook?

Some notes from @untitaker:

sending the parameters should definetly be behind sendDefaultPii=true, because the higher-level guidance that we should communicate is to not send PII by default. I don't think it makes as much sense to exhaustively enumerate every piece of the event payload and whether it is PII. that is always dependent on what you're going to put there. for example, if you know a particular db parameter value is not PII because of some platform peculiarity, advice like "this location in the event is PII" doesn't apply and you should feel free to send it

• anything that is typically PII by nature has to be behind sendDefaultPii. this implies that db parameters are, but we don't need to document that
• span descriptions should not contain high-cardinality fields, because we attempt to group db queries together by description

[brustolin]

We need to update documentation to explain that user need to use parameterised queries instead of writing filter values direct in the query, because this may leak PII.

[kahest]

There's been 3 recent RFCs about scrubbing and documenting PII:

• https://github.com/getsentry/rfcs/blob/main/text/0038-scrubbing-sensitive-data.md
• https://github.com/getsentry/rfcs/blob/main/text/0062-controlling-pii-and-credentials-in-sd-ks.md
• https://github.com/getsentry/rfcs/blob/main/text/0070-document-sensitive-data-collected.md

This issue should be re-written to take the outcome of the RFCs into account.