Scrub credentials, session values, personal data, connection strings and full request bodies. Error reports collect more context than logs because they are meant to help you reproduce a bug, and that context is often exactly the sensitive part. Decide the fields in advance and test them.
What an error report usually contains
A typical report includes the exception message and stack trace, the request URL and method, request headers and cookies, parts of the request body, user details, environment names, and sometimes local variables. Each is useful for debugging, and each can hold a secret.
The OWASP Logging Cheat Sheet lists data to exclude or protect: session identification values, access tokens, passwords, database connection strings, encryption keys and primary secrets, payment data, and sensitive personal information. Error reports are a log destination with extra detail, so the same list applies.
Field by field
| Field | Risk | Action |
|---|---|---|
| Exception message | Can embed a connection string or a user value | Review messages, avoid putting values in them |
| Stack trace | Usually safe, shows paths | Keep |
| Request URL | Tokens in query strings | Strip or mask the query |
| Request headers | Authorization, cookies | Drop sensitive headers |
| Request body | Passwords, personal data | Do not send, or allow list fields |
| Local variables | Anything in memory | Disable, or allow list |
| User info | Email, name | Send an opaque ID |
| Breadcrumbs | Recorded clicks and inputs | Mask input values |
Steps
- Read the configuration of your error reporting library. Find the options that control bodies, headers, cookies and variables, and turn off what you do not need.
- Add a scrubbing hook that runs before sending, so it applies to every report.
- Deny headers by name: authorization, cookie, set-cookie, api key headers.
- Mask URL query values with an allow list of safe parameters.
- Write exceptions without embedded values. Use a short message and put identifiers in separate, reviewed fields.
- Test with canary values. See test log redaction with canary values.
- Check where reports are stored and who can read them. Reports are often visible to the whole engineering group.
Mistakes we see
Treating an error tracker as an internal tool, so scrubbing is skipped. Leaving defaults on after an upgrade. Letting a developer paste a report into a public issue or chat. Retaining reports for a year when thirty days would do.
Related reading
For one framework's built in tools, see Django sensitive variables and error report secrets. For production debug pages, see what Django DEBUG True exposes in production.
Quick check
Is a stack trace sensitive?
Usually not by itself, but it reveals code paths and library versions. Restrict access, and avoid showing it to end users.
Should error reports include the request body?
Not by default. Use an allow list of fields if you need some of the body to reproduce bugs.
Safeguard's dependency scanning also covers the error reporting libraries in your SBOM. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
