# Workflow: the three-layer data scrubbing stack

No single layer catches everything. Scrub in the SDK, on the server, and with custom rules, in that order of preference.

## Layer 1: beforeSend in the SDK

Scrub before data leaves the host. This is the only layer that guarantees sensitive data never reaches Sentry's servers:

```js
Sentry.init({
  beforeSend(event) {
    if (event.user) delete event.user.email;
    return event;
  },
});
```

Use it for the secrets you know about: API keys in headers, tokens in query strings, PII in user context. Keep the callback fast and total; a throwing beforeSend drops the event.

## Layer 2: server-side defaults

Server-side scrubbing is on by default and catches credit-card-shaped values plus keynames like password, secret, api_key, token, and bearer. Leave it on. Configure at the org level for consistency, knowing org settings override project settings. Use Safe Fields for the rare key that must stay (a field literally named `token` that holds a non-secret), and additional sensitive fields for your own keynames.

## Layer 3: advanced rules

For patterns only your app produces, write Advanced Data Scrubbing rules. Each rule has a method (Remove, Mask, Hash, Replace), a data type (what to look for, including custom regex), and a source (which part of the event to search):

```
[Mask] [custom regex for internal account IDs] from [extra.account_id]
```

Sources let you test conservatively: scope a rule to one event attribute first, then widen. Note the precedence: advanced rules apply even to fields in Safe Fields.

## Rollout order

1. beforeSend for known secrets (deploy with the app).
2. Server-side defaults review: confirm they are on, add your keynames.
3. Advanced rules for the leftovers, tested narrow first.

## Verify

Send test events containing each secret type through all three layers and confirm redaction in the stored event. Re-audit quarterly: new features add new secret shapes, and scrubbing rules do not write themselves.