How to Mask PII in Logs, JSON, and HAR Before Sharing

Before sharing a log, JSON payload, or HAR, make a working copy, remove fields the recipient does not need, replace necessary identifiers with stable placeholders, and inspect the result as if you were the recipient. If the file contains a live credential, masking the copy is not remediation: revoke the exposed credential immediately, then rotate it. Remove exposed copies where possible, notify the responsible security or service owner, and inspect access since the earliest possible exposure.

Know what should not leave the trust boundary

OWASP recommends that session identifiers, access tokens, passwords, connection strings, encryption keys, sensitive personal data, and payment data normally be removed, masked, sanitized, hashed, or encrypted rather than logged directly. File paths, internal network names and addresses, names, phone numbers, and email addresses may also need special treatment.

That gives a practical review list for support tickets, AI prompts, chat, and vendor uploads:

• Authorization, API-key, and custom authentication headers
• Cookies, session IDs, refresh tokens, signed URLs, and password-reset links
• Request and response bodies containing account, health, support, or payment data
• Email addresses, phone numbers, names, postal addresses, and government identifiers
• Query parameters and URL paths containing user IDs, tokens, or document names
• Internal hostnames, private IP addresses, file-system paths, database names, and stack traces with environment details

Do not remove every timestamp, status code, request ID, or error name by reflex. Those fields can be essential for correlation. The aim is data minimization: keep what is required to diagnose the issue and remove what is not.

Use this ordered pre-share workflow

1. Define the question and recipient. Write down what the other party needs to establish—for example, “why did request 42 return 403?” A narrow question makes unrelated bodies, users, and time ranges easier to discard.
2. Create a disposable working copy. Keep the restricted original in its approved location. Never edit the only incident artifact, and do not paste the raw source into another online service merely to sanitize it.
3. Reduce the capture first. Filter the log to the relevant time window and services. For a HAR, reproduce the issue in a clean session with only the necessary tab and requests when practical.
4. Choose the safer HAR export. Chrome DevTools offers a sanitized HAR export that excludes headers such as Cookie, Set-Cookie, and Authorization. Use it as the starting point, but do not assume it catches secrets in query strings, bodies, custom headers, URLs, or application data.
5. Remove whole fields before masking values. If a request body, response body, cookie block, or stack-trace section is not needed, delete it. Fewer retained fields mean fewer patterns that a masking rule can miss.
6. Replace necessary identifiers consistently. Use placeholders such as [USER_01], [EMAIL_01], [TOKEN_01], and [INTERNAL_HOST_01]. Reuse the same placeholder for the same value within this one artifact so request relationships remain visible; do not reuse a mapping across unrelated cases.
7. Validate structure and review the diff. Parse JSON or HAR again after editing. Search both keys and values for secret names, email syntax, bearer strings, cookies, private hosts, and organization-specific identifiers. Read request URLs, headers, and bodies separately, then compare the sanitized copy with the original in a trusted environment.
8. Test usefulness, then share narrowly. Confirm the sanitized copy still contains the request sequence, timestamps, status, and error needed for the stated question. Send it through an approved, access-controlled channel with the smallest practical audience and retention period.
9. Clean up the working material. Delete temporary raw exports and local mapping files when policy permits. If a ticket or chat no longer needs the attachment, remove it there too rather than relying on obscurity.

Stable placeholders preserve correlation, but they do not make a dataset anonymous. A rare timestamp, order amount, hostname, or free-text message can still identify a person when combined with other information. Review context, not just obvious patterns.

Preserve debugging context without preserving live values

Original:

2026-09-05T09:14:22Z request_id=req-7f2 user_email=alex@example.com
GET https://billing.internal/accounts/9481?invite_token=<live-token>
Authorization: Bearer <live-access-token>
response_status=403 error=scope_missing

Shareable copy:

2026-09-05T09:14:22Z request_id=req-7f2 user_email=[EMAIL_01]
GET https://[INTERNAL_HOST_01]/accounts/[ACCOUNT_01]?invite_token=[TOKEN_01]
Authorization: [REDACTED_CREDENTIAL_01]
response_status=403 error=scope_missing

The second copy retains time, request correlation, route shape, response status, and error. It does not reveal the person, account, internal host, invite token, or bearer credential.

For JSON, keep valid JSON rather than inserting comments or partially deleting quotes. For a HAR, preserve the object shape required by the viewer, but remove unnecessary entries and sensitive fields. After any manual change, import or parse the file again; a syntactically broken artifact is neither safe nor useful.

If a credential was exposed, switch to incident handling

Redaction changes what a future reader sees. It cannot invalidate a token already copied into a ticket, prompt, email, terminal recording, or HAR. Treat the secret as potentially compromised from the moment it entered a location outside its intended boundary.

1. Revoke first. Disable the token, session, API key, certificate, or signed link through the issuing system as quickly as possible. OWASP's secrets guidance calls for immediate revocation of exposed keys.
2. Rotate second. Create a replacement and update legitimate consumers. Verify that the old credential no longer works; issuing a new value without invalidating the old one is not enough.
3. Contain copies. Remove the attachment or message where the platform allows it, restrict ticket or document access, and clear temporary exports. Deletion may not erase backups or copies already made, so do not use it as a substitute for revocation.
4. Notify and investigate. Contact the service owner or security response path. Record when and where the exposure may have occurred, then inspect secret-manager, authentication, application, and provider access logs for unexpected use.
5. Fix the source. Stop the credential from being logged again, add tests for the offending field, and review adjacent log paths. Sanitizing each export forever is weaker than preventing collection at the source.

Primary sources

• OWASP Logging Cheat Sheet
• OWASP Secrets Management Cheat Sheet
• Chrome DevTools Network reference: HAR export