Scrubbing Sensitive Data from Error Reports

Error reports are treasure troves of debugging information — but they're also minefields of sensitive data. A stack trace that leaks a database password, a breadcrumb that captures a credit card number, or an API response containing a customer's SSN can turn your error tracking system into a compliance liability. Sensitive data scrubbing is the practice of automatically removing or masking PII, secrets, and other dangerous information before error events leave your application.

This guide explains why data scrubbing matters, what it catches, and how to implement it properly so you get rich debugging context without the legal risk.

Why leaked data in error reports is a real problem

Error payloads are rich by design. To help you debug fast, they capture full stack traces, local variables, request headers, response bodies, and the breadcrumb trail that led to the crash. That context is what makes the difference between "an error happened" and "here's exactly what the user did and what failed."

But that same richness creates risk. Consider what a typical error might contain:

• Headers: Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... (a JWT token)
• Request body: {"email":"user@example.com","ssn":"123-45-6789","credit_card":"4532-xxxx-xxxx-1234"}
• Environment variables: DATABASE_URL=postgres://admin:super-secret-password@db.example.com
• Local variables: sessionToken, apiKey, authorizationCode
• Logs and breadcrumbs: User 12345 accessed /admin/reports; SQL query: SELECT * FROM users WHERE password='...

If any of these events reach your error tracker unfiltered, you've just stored sensitive data in someone else's system — potentially violating GDPR, PCI-DSS, HIPAA, or your own privacy policy. And if your error tracker gets breached, that sensitive data is exposed.

How sensitive data scrubbing works

Scrubbing is the automated process of identifying and removing or masking sensitive patterns before events leave your application. It happens before the event is sent to your error tracker, so the dangerous data never reaches the server in the first place.

Most error trackers, including LightTrace, apply scrubbing at two levels:

Server-side scrubbing: The error tracker applies built-in rules to mask common patterns like credit card numbers, SSNs, and API keys as events arrive. This is a safety net, but it's not foolproof — the data still passes through the system in flight.

Client-side scrubbing: Your application's SDK scrubs events before sending them, using rules you define. This is more powerful because you know your own secrets — the exact header names, environment variables, and field names that carry sensitive data in your stack.

The best approach combines both: set client-side scrubbing rules for your specific secrets, and rely on server-side scrubbing as a failsafe for patterns you missed.

Patterns that need scrubbing

A good scrubbing strategy targets the most common data leaks:

Authentication tokens and API keys:

• JWT tokens: Authorization: Bearer eyJhbGc...
• API keys: api-key: sk_live_abc123...
• OAuth tokens: access_token: gho_abc123...
• Session tokens: sessionId, authToken, etc.

Personal information:

• Credit card numbers: 4532-1234-5678-9012 (16 digits)
• Social Security Numbers: 123-45-6789
• Phone numbers: (555) 123-4567
• Email addresses and names (context-dependent; may be necessary for debugging)

Credentials:

• Database connection strings with passwords: postgres://admin:password@host
• AWS keys: AKIAIOSFODNN7EXAMPLE
• Private keys and certificates

Sensitive request/response data:

• Response bodies that contain user PII or financial data
• Query parameters containing tokens or identifiers
• Custom headers with sensitive values

Implementing scrubbing in your SDK

When you add error tracking to your application, LightTrace's Sentry-SDK-compatible support means you get built-in scrubbing hooks. You define patterns and rules once, and the SDK applies them to every event before sending it out.

Here's a basic setup for JavaScript/Node:

import * as Sentry from "@sentry/node";

Sentry.init({
  dsn: "https://<key>@your-lighttrace-host/1",
  environment: "production",
  beforeSend(event) {
    // Scrub credit card numbers from breadcrumbs and stack trace
    if (event.breadcrumbs) {
      event.breadcrumbs = event.breadcrumbs.map((crumb) => {
        if (crumb.message) {
          crumb.message = crumb.message.replace(
            /\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b/g,
            "****-****-****-****"
          );
        }
        return crumb;
      });
    }
    return event;
  },
});

For Python with Django:

import sentry_sdk
from sentry_sdk.integrations.django import DjangoIntegration

def scrub_event(event, hint):
    # Remove sensitive headers
    if "request" in event and "headers" in event["request"]:
        headers = event["request"]["headers"]
        if "Authorization" in headers:
            headers["Authorization"] = "***"
        if "Cookie" in headers:
            headers["Cookie"] = "***"
    return event

sentry_sdk.init(
    dsn="https://<key>@your-lighttrace-host/1",
    integrations=[DjangoIntegration()],
    before_send=scrub_event,
)

The beforeSend hook (or before_send in Python) fires for every event before it leaves your app. You can inspect it, modify it, or drop it entirely. This is where you implement your scrubbing logic.

Define your scrubbing rules

Start with a checklist of what your app might leak:

1. List your secrets: What environment variables, tokens, and credentials does your app use? Document them.
2. Map where they appear: Do they live in headers, query strings, request bodies, local variables? Log them?
3. Write patterns: Convert each to a regex or exact-match rule. Test it.
4. Apply progressively: Start with the most common leaks (auth headers, tokens), then add more granular rules.

A good rule is specific enough to catch the leak but broad enough to work across different formats:

# Scrub JWT tokens (common pattern: Bearer <long.base64.string>)
r"Bearer\s+eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]*"

# Scrub AWS key IDs
r"AKIA[0-9A-Z]{16}"

# Scrub generic "password" or "token" fields (key-value)
r"([\"']?(?:password|token|secret|api[_-]?key|auth)[\"']?\s*[:=]\s*)[\"']?[^\s\"']+[\"']?"

Beyond manual scrubbing

Defining patterns manually is tedious and error-prone. Some teams use dedicated data redaction libraries or services that learn common PII patterns over time. Others rely on a combination of:

• Allowlisting: Only capture specific, safe fields (the opposite of scrubbing). Slower but more thorough.
• Classification tagging: Mark fields as "sensitive" at the application layer, then scrub them automatically.
• Tokenization: Replace real values with opaque tokens, then decrypt only when needed for debugging.

For most teams, though, a well-tuned beforeSend hook with a few critical patterns catches 95% of leaks without the complexity.

Auditing what you're capturing

The hardest part of scrubbing isn't implementing it — it's knowing what you need to scrub. Start by:

1. Reviewing actual error events in your error tracker. What fields are being captured that shouldn't be?
2. Running a security audit of your application. What secrets does it handle? Where might they leak?
3. Testing scrubbing rules in staging with realistic error payloads before pushing to production.
4. Monitoring for patterns you might have missed. Set up periodic reviews of sample events.

The goal is defense in depth: error tracking best practices include scrubbing as a core part of your security posture, not an afterthought. Combined with proper error grouping, scrubbing helps you build a system where you can reduce MTTR without compromising user privacy. By combining automatic server-side scrubbing with application-layer rules you define, you keep the debugging power of rich error context while protecting user data.

Good scrubbing means your stack traces stay readable and actionable, your breadcrumbs tell the full story, but your secrets stay secret. And when you're debugging production errors at 3 a.m., you'll be grateful your error tracker has all the context you need — without the compliance headache.