Apps shipping a Sentry DSN

What this finding means, and why it is not a leak

A Sentry DSN tells the SDK which project to send events to. Client DSNs are meant to be embedded in the thing being monitored, which is why they also sit in the JavaScript bundle of most websites that use Sentry.

We record it in 723 apps and score it as information rather than as a weakness. A DSN permits sending events to a project. It does not permit reading them, so finding one does not expose your error data.

The real question is what your crash reports collect

Error monitoring captures context, and context is where personal data accumulates. Breadcrumbs record the screens and actions preceding a crash. Request bodies and headers can be attached to network errors. User context is often populated with an account identifier or an email address to make triage easier. Local variables may be captured in stack frames.

That makes your error monitor a destination for personal data and the vendor a processor acting on your behalf. It is declarable in the Google Play Data Safety form, and it is the kind of flow that is routinely missed there, because a crash reporter does not feel like analytics. Apps in this category frequently also appear in the Data Safety mismatch category for exactly that reason.

The second, smaller issue is abuse of the DSN itself. Anyone holding it can post events to your project, which wastes quota and can bury a real incident in noise.

How to act on it

• Confirm the DSN is a client DSN. An internal or legacy DSN carrying write-beyond-ingest scope does not belong in a shipped app.
• Scrub personal data before it leaves the device, using beforeSend rather than relying only on server-side scrubbing.
• Review what your breadcrumbs capture. Default integrations record user interactions and network requests, which is usually more than you intended to collect.
• Decide deliberately whether to attach user context, and prefer an opaque internal id to an email address.
• Declare the collection and the sharing with your monitoring vendor in the Data Safety form.
• Set rate limits and spike protection on the project so a flood of forged events cannot exhaust your quota.

How we detect it

The DSN's structure is matched in the APK's resources and compiled code, and only its scheme prefix and a coarse length bucket are recorded. We do not send anything to the project, and we make no attempt to read its events.