Response Sanitization

Protect sensitive data in test results by automatically redacting personally identifiable information (PII) and secrets from response payloads.

Overview

When tests run, Pingward stores response data for debugging and analysis. Response sanitization automatically redacts sensitive information before storage, ensuring:

• Compliance with data protection regulations (GDPR, CCPA, etc.)
• Protection against accidental exposure of customer data
• Safe storage of API responses containing PII
• Secure test result viewing by team members

Sanitization happens on the worker before results are sent to the database, so sensitive data never reaches storage.

Sanitization Modes

Each test can have its own sanitization configuration. Choose the mode that matches your data sensitivity requirements.

None

No sanitization applied - raw responses stored as-is

When to use:

• Internal APIs with no sensitive data
• Public endpoints that return only non-sensitive information
• Development/testing environments with synthetic data

Warning: Only use this mode if you're certain the API responses contain no PII, credentials, or secrets.

Standard (Default)

Redacts common PII patterns:

• Email addresses: user@example.com → [REDACTED_EMAIL]
• Phone numbers: +1-555-123-4567 → [REDACTED_PHONE]
• Social Security Numbers: 123-45-6789 → [REDACTED_SSN]
• Credit card numbers: 4532-1234-5678-9010 → [REDACTED_CREDIT_CARD]

Example:

Input response:

{
  "user": {
    "name": "John Doe",
    "email": "john.doe@example.com",
    "phone": "+1-555-123-4567"
  }
}

Sanitized result:

{
  "user": {
    "name": "John Doe",
    "email": "[REDACTED_EMAIL]",
    "phone": "[REDACTED_PHONE]"
  }
}

When to use:

• Customer-facing APIs returning user data
• E-commerce endpoints with payment information
• Most production APIs

Strict

Includes all Standard patterns plus:

• API keys: sk_live_abc123... → [REDACTED_API_KEY]
• Bearer tokens: Bearer eyJhbG... → [REDACTED_TOKEN]
• AWS keys: AKIA... → [REDACTED_AWS_KEY]
• Private keys: -----BEGIN PRIVATE KEY----- → [REDACTED_PRIVATE_KEY]
• IP addresses: 192.168.1.1 → [REDACTED_IP]
• Passwords in JSON: "password": "secret" → "password": "[REDACTED]"

When to use:

• APIs that return authentication credentials
• Administrative endpoints
• Infrastructure monitoring endpoints
• Third-party API integrations that echo secrets

Custom

Define your own redaction patterns using regular expressions.

When to use:

• Industry-specific identifiers (patient IDs, account numbers)
• Custom proprietary data formats
• Additional patterns beyond Standard/Strict modes

Example patterns:

Patient ID:
Pattern: \b[A-Z]{2}\d{6}\b
Replacement: [REDACTED_PATIENT_ID]

Internal Account Number:
Pattern: ACC-\d{8}
Replacement: [REDACTED_ACCOUNT]

Transaction ID:
Pattern: TXN-[A-Z0-9]{12}
Replacement: [REDACTED_TRANSACTION]

Configuring Sanitization

When Creating a Test

1. Navigate to Tests → New Test
2. Scroll to the Response Sanitization section
3. Select your sanitization mode
4. For Custom mode:
   • Click Add Pattern
   • Enter the regex pattern (e.g., \b[A-Z]{2}\d{6}\b)
   • Add multiple patterns as needed

When Editing a Test

1. Open the test details page
2. Click Edit
3. Update the Response Sanitization configuration
4. Save changes

The new sanitization rules apply to all future test executions. Previously stored results are not modified.

Custom Pattern Examples

Example 1: UUID Identifiers

If your API returns UUIDs that should be redacted:

Pattern: [a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}

Before:

{"order_id": "550e8400-e29b-41d4-a716-446655440000"}

After:

{"order_id": "[REDACTED]"}

Example 2: Order Numbers

Redact order numbers in format ORD-12345678:

Pattern: ORD-\d{8}

Example 3: API Response Codes

Redact single-use verification codes:

Pattern: "verification_code"\s*:\s*"\d{6}"

Before:

{"verification_code": "123456"}

After:

{"verification_code": "[REDACTED]"}

Regular Expression Tips

• Use \b for word boundaries to avoid partial matches
• Escape special characters: \. for literal dots, \- for hyphens
• Test patterns carefully to avoid over-redaction
• Use non-capturing groups (?:...) for performance
• Patterns are case-insensitive by default

Best Practices

Start with Standard Mode

For most production APIs, Standard mode provides good protection without over-redacting. Upgrade to Strict if needed.

Test Your Patterns

Before deploying custom patterns:

1. Create a test with sample data
2. Run the test manually
3. Review the sanitized results
4. Adjust patterns if needed

Document Your Patterns

Add clear descriptions to custom patterns so team members understand what's being redacted.

Avoid Over-Sanitization

Don't redact data you need for debugging. Balance security with operational needs:

• ✅ Redact: Customer emails, payment info, passwords
• ❌ Don't redact: Status codes, error messages, timestamps

Review Regularly

As your APIs evolve, review sanitization rules quarterly to ensure they still match your data:

• New API fields with sensitive data?
• Deprecated patterns no longer needed?
• Compliance requirements changed?

Security Considerations

What Sanitization Protects

• ✅ Accidental exposure via test result viewing
• ✅ Data leaks from database backups
• ✅ Unauthorized access to test history
• ✅ Compliance violations from stored PII

What Sanitization Does NOT Protect

• ❌ Network traffic (use HTTPS)
• ❌ Live test execution (sanitization happens after)
• ❌ Worker logs (configure worker logging separately)
• ❌ Alert notifications (alerts don't include response bodies)

Combining with Access Controls

Sanitization is one layer of defense. Also implement:

• Role-based access control (RBAC) for test results
• Audit logs for sensitive test access
• IP allowlisting for admin access
• Regular security reviews

Limitations

• Performance: Complex custom patterns may increase processing time slightly
• Partial matches: Regex patterns may miss unusual formats
• JSON structure: Field names are not redacted, only values
• Binary responses: Sanitization only works on text-based responses

FAQ

Q: Can I change sanitization mode for an existing test?

Yes. Edit the test and update the mode. Future executions use the new rules, but past results remain unchanged.

Q: Are old test results re-sanitized when I change modes?

No. Sanitization only applies to new test executions after the change.

Q: What happens if my regex pattern is invalid?

The test will fall back to the default Standard mode and log a warning. Check the test execution logs for pattern errors.

Q: Can I disable sanitization entirely for a test?

Yes, set the mode to None. Only do this for non-sensitive endpoints.

Q: Do routing rule notifications include sanitized data?

No. Alert notifications (Slack, email, SMS) contain error summaries but never include full response bodies, so sanitization doesn't affect alerts.

Q: How can I verify my custom patterns are working?

After creating the test with custom patterns:

1. Run the test manually using "Run Now"
2. View the test result details
3. Check the response body to confirm redaction

Related Topics

• Creating Tests
• Test Results
• Data Retention