Check what your error reports contain before launch, and filter sensitive data at the source

An error event is more than a stack trace

When an application reports an exception, the report can include the request that triggered it: the address with its query string, headers and cookies, form fields, the user, database queries and the values of local variables at each stack frame. That context is what makes the report useful, and it is also what makes it risky. The Sentry Python documentation lists query strings, database queries and stack-local variables among the places that may hold sensitive data, and says the default scrubber, which removes denylisted items such as passwords, authentication values, sessions, cookies and CSRF tokens, does not search nested data unless you turn that on. Before you launch, take a typical request and list what an event for it would hold.

• Write down each header, parameter and user field in a typical request, using invented values.
• Mark the ones you would not want stored by a third party, including anything that identifies a person.

Decide where the scrubbing happens

There are three places. In the SDK, the data never leaves your application, but a change needs a redeploy. On the server side, the tool does not store the data and you change the rules in its interface, which applies to new events. A local relay is a third option, with the configuration changeable without a redeploy. For data you must never send, the SDK is the strongest choice, because the value never leaves your infrastructure. Server-side rules are a useful second layer and a quick way to respond to a surprise, but because they apply to new events they are not a reason to send a secret first and clean it up later.

• Use the SDK hook for fields that must never leave the application.
• Use server-side rules as a second layer and for fast changes.
• Treat anything already stored as a separate clean-up question for the account owner.

Use the hook, and read the option defaults

The before_send hook receives the event before it is sent and can return an edited event or nothing at all, in which case the event is dropped. Use it to remove fields by name and to mask patterns inside messages. The options reference says send_default_pii defaults to None, and that when it is enabled, integrations add some personally identifiable data you should scrub if you do not want it sent. The Python page also says this option will be phased out in favour of a newer data_collection option, so read the documentation for the SDK version you actually use rather than copying an old snippet. Keep the list of fields to remove in one place that a reviewer can read.

• Name the SDK version in the settings summary so the next person knows which documentation applies.
• Prefer an explicit list of fields to remove over a hope that defaults are enough.

Test with invented secrets, and how the paid job is accepted

A filter that was never tested is a guess. Raise a test error in a non-production environment from a request that carries invented values that look like secrets and personal data, in the request, in an exception message and in a local variable. Then open the stored event and look for them. The error-tracking setup job treats this as an acceptance check: the event must arrive with the agreed fields removed or masked, and the settings summary lists what is filtered and what was left at its default. This is a technical control, not legal advice, and whether you may send error data to a third party at all is your decision under your own policies. Send the stack in general terms and whether requests carry personal data, never the data itself.