Audit API Payloads for Data Privacy

Format your API request and response payloads for visual inspection

Before any automated scanning, a formatted, human-readable view of your payloads lets you identify structural patterns and obvious problems before the tools do. Paste your raw API request body and response body into the JSON Formatter & Validator separately. The prettified output makes it immediately visible: deeply nested objects that may contain PII at unexpected depths (e.g., user.profile.contact.emergency_contact.phone), large arrays that may contain repeated personal data records, metadata fields that may contain internal system information not intended for external clients (internal IDs, server-side tracking fields, implementation details), and response fields that expose more data than the client actually uses (over-fetching — sending a full user object when only name is needed). Document the fields you see — you'll use this inventory in Steps 2–4.

Tip: Use the JSON Formatter's search or key-highlighting feature to locate all fields with names like 'email', 'phone', 'name', 'address', 'ssn', 'pan', 'aadhaar', 'dob' — these are your PII inventory.

Scan for embedded credentials, tokens, and API keys in the payload

API responses and logs frequently contain secrets that shouldn't be there: an OAuth token returned in a response body instead of just in headers, a webhook payload that includes the signing secret, an error response that leaks an internal connection string, a debug field that shows a private key in development mode, or an internal API key embedded in a third-party integration response. Use the Secret Scanner to scan both your request and response payloads for: API key patterns (AWS AKIA*, Stripe sk_live_*, Google AIza*, GitHub ghp_*), JWT-shaped strings in unexpected fields, RSA/EC private key headers (-----BEGIN PRIVATE KEY-----), database connection strings containing passwords, .env variable patterns (KEY=value), and high-entropy strings that may be unrecognised credential formats. Each match should be investigated — not all high-entropy strings are secrets, but all secrets are high-entropy strings.

Tip: Pay special attention to error responses — APIs often include internal debugging information in error payloads that should never reach production clients. Run the scanner on your 400/401/500 error response samples too.

Anonymise all PII fields found in the payload inventory

Using the field inventory from Step 1, pass the payloads through the Data Anonymizer to replace all PII with format-valid synthetic equivalents. This step is distinct from the secret scanning in Step 2 — secrets are credentials and cryptographic material; PII is personal information about individuals. The anonymizer handles: names (replaced with synthetic names of similar length and format), email addresses (replaced with @example.com equivalents that pass validation), phone numbers (replaced with numbers in the same format and country code), physical addresses (replaced with addresses in the same region that don't map to real locations), national ID numbers (Aadhaar, PAN, SSN — replaced with checksum-valid synthetic equivalents), dates of birth (replaced with nearby dates that preserve age bracket), and IP addresses (replaced with addresses in the same /24 range). After anonymisation, re-run the JSON Formatter to verify the payload structure is still valid.

Tip: For API responses that include user IDs or account numbers, consider whether these should be anonymised or pseudonymised. Pseudonymisation (replacing with a consistent fake ID) allows you to trace requests across logs; full anonymisation breaks that traceability.

Decode and audit JWT claims for sensitive data exposure

JWTs that appear in your API request or response payloads deserve a dedicated audit step. Use the JWT Decoder to inspect both the header and payload claims of any tokens found. Check for: (a) Sensitive data in claims — JWTs are base64url encoded, not encrypted. Any claim in the payload (sub, email, name, role, custom claims) is readable by anyone who intercepts the token unless it's additionally encrypted (JWE). Never put sensitive PII in JWT claims if the token is transmitted over HTTP. (b) Weak algorithms — alg: 'none' in the header disables signature verification entirely; alg: 'HS256' with a guessable secret is brute-forceable. RS256 or ES256 (asymmetric) are preferred for production. (c) Excessive scope — a token that grants admin access when only read access is needed violates the principle of least privilege. (d) Long-lived tokens — exp values set years in the future mean a stolen token can be used indefinitely. Rotate short-lived access tokens (15 min–1 hour) with long-lived refresh tokens in HttpOnly cookies.

Tip: If JWTs appear in your API response body (rather than only in Set-Cookie headers), that's an architectural flag — tokens in response bodies can be stolen via XSS. Prefer delivering tokens via HttpOnly Secure SameSite=Strict cookies.

Replace any remaining real data with synthetic equivalents for safe storage

After cleaning secrets (Step 2) and anonymising PII (Step 3), the final step ensures that any real records used as examples, documentation samples, or test fixtures in your codebase are replaced with fully synthetic equivalents generated from scratch. Use the Fake Person Generator to create a set of synthetic user records that match your schema — same fields, same formats, but entirely fictional from the start. Replace any example payloads in your API documentation, Postman collections, README files, fixture JSON files, and seed scripts with these synthetic records. This is particularly important for: API documentation published publicly (never use real customer data as examples), Postman/Insomnia collections shared with contractors, test fixtures committed to version control, and error response examples that may contain real request data from a debugging session.

Tip: After replacing all example data, run a final Secret Scanner pass on your entire codebase — not just the payloads — to confirm no real credentials or PII remain in your repository history or configuration files.