How to Prevent Sentry DSN Leakage

First: which Sentry credential did you actually leak?

The single most important fact about this incident is one most write-ups skip. The string people call a "Sentry DSN" in postmortems is almost never the public DSN. Sentry projects expose at least four credentials that look superficially similar, often live in the same config file, and carry wildly different blast radii. Picking the right rotation depends entirely on which one of these you actually committed.

If you grep your repo for "sentry" and find only the first format, you have a billing and noise incident, not a confidentiality one. If you find sntryu_ or sntrys_, or a DSN with two segments before @, you have a real exposure. The rest of this page assumes the worse case and tells you how to scope the damage.

What attackers actually do with each credential

With only the public DSN

The realistic attacks are quota exhaustion and noise. A scanner finds your DSN in main.js and starts POSTing synthetic exceptions to /api/<projectId>/store/. Two outcomes follow: either you burn through your monthly event allotment and start paying overage rates, or real production errors get buried under thousands of fake ones and your on-call team stops trusting Sentry. Both happen. The mitigation is a two-click change in project settings — Allowed Domains plus Inbound Filters — and neither is on by default.

With a user auth token (sntryu_)

This is the credential whose leak teams underestimate the most. The attack is straightforward exfiltration of everything Sentry has stored for you. One curl request lists every project in your org. A second fetches recent events with ?full=true, and the event payloads contain the parts of an HTTP request your code captured around the exception — request bodies, query strings, headers, cookies, and whatever you passed to Sentry.setUser. Most teams pass raw customer emails. Some accidentally pass authorization headers. A read-events token gives an attacker your last 30 to 90 days of those payloads in a single bash loop.

With an org or internal-integration token (sntrys_)

The same event-exfiltration attack works, but the more interesting threat is poisoned source maps. Sentry resolves obfuscated stack frames against the source maps you uploaded for a given release identifier. An attacker with a write-capable org token can run sentry-cli releases files upload-sourcemaps against a release you already shipped, and from that moment every error your engineers click on points at lines of code that do not exist in your repo. It is a great way to hide a real attack — your team chases ghost stack frames while the actual exploit goes uninvestigated.

# Three lines of bash is all it takes once a user auth token is exposed:

# 1. List every project the issuing user can see
curl -H "Authorization: Bearer sntryu_LEAKED_TOKEN" \
  https://sentry.io/api/0/organizations/your-org/projects/

# 2. Pull recent events with full request payloads (often contain PII)
curl -H "Authorization: Bearer sntryu_LEAKED_TOKEN" \
  "https://sentry.io/api/0/projects/your-org/your-project/events/?full=true"

# 3. Upload a malicious source map to a shipped release
SENTRY_AUTH_TOKEN=sntryu_LEAKED_TOKEN sentry-cli releases files \
  "1.42.0" upload-sourcemaps ./poisoned-dist

Preventing the next leak

Three patterns cover almost every recurring Sentry credential leak. None of them are unique to Sentry — they are unique-feeling because Sentry's docs blur the line between the safe public DSN and the dangerous auth tokens, and developers copy-paste both into the same config file.

• Auth tokens live only in environment variables. sentry-cli reads SENTRY_AUTH_TOKEN from the process environment. There is no operational reason to write the token into a config file, a Makefile, or a shell script that gets committed. Put it in your CI provider's secrets, a vault, or your runtime's env, and reference the name everywhere else.
• Pre-commit scanning targets the literal prefixes. sntryu_ and sntrys_ are unique enough that a gitleaks rule has no false positives. The same goes for the legacy DSN format with a :-separated secret. Catch them before the push leaves the laptop, then catch them again on the PR diff in CI.
• Public DSN hardening lives in Sentry, not your code. Enable Allowed Domains on every project key, set a per-key rate limit, and use a separate DSN per environment. The point is that even if a scanner picks up your public DSN, it cannot do meaningful damage from an origin that is not in your allowlist.

Gitleaks rules that catch the dangerous credentials

# .gitleaks.toml — rules people actually leak, not the public DSN
[[rules]]
id = "sentry-user-auth-token"
description = "Sentry user auth token"
regex = '''sntryu_[A-Za-z0-9]{32,}'''

[[rules]]
id = "sentry-org-auth-token"
description = "Sentry organization or internal-integration token"
regex = '''sntrys_[A-Za-z0-9]{32,}'''

[[rules]]
id = "sentry-legacy-dsn-with-secret"
description = "Old-format Sentry DSN that still embeds a secret"
regex = '''https?://[a-f0-9]{32,}:[a-f0-9]{16,}@[^/]+\.ingest\.sentry\.io/[0-9]+'''

Safe vs unsafe usage in code

Right — only the public DSN reaches the browser, with PII stripped before send:

// src/lib/sentry.client.ts
import * as Sentry from '@sentry/browser';

Sentry.init({
  dsn: import.meta.env.PUBLIC_SENTRY_DSN, // public by design
  release: import.meta.env.PUBLIC_SENTRY_RELEASE,
  // Strip the request body before it leaves the device — most PII lives there
  beforeSend(event) {
    if (event.request) {
      delete event.request.data;
      delete event.request.cookies;
    }
    return event;
  }
});

Wrong — the auth token gets compiled into the bundle and is now public:

// DO NOT do this — anyone who downloads main.js owns your error history
export const sentry = {
  dsn: 'https://abc123@o1.ingest.sentry.io/42',
  authToken: 'sntryu_PLEASE_NEVER_DO_THIS' // belongs in CI env only
};

The pattern that catches teams off-guard: a developer copies the sentry-cli source-map upload snippet from the docs into a build script, the build script gets committed, and the auth token rides along. A pre-commit scan would have caught the sntryu_ prefix before it ever left the laptop.