PII in URLs — The Data Leak Nobody Checks

Short answer: a URL is recorded in more places than almost any other piece of data: analytics tools, server and CDN logs, browser history, bookmarks, and the referrer sent to other sites. Masking protects what is on the page. It does not protect the address of the page. If a URL contains an email address, a name, or a token, that value has been copied to every one of those places.

Table of Contents

1. How Personal Data Gets Into URLs
2. Where a URL Travels
3. Why Masking Does Not Help
4. How to Find It
5. How to Fix It
6. Key Takeaways

How Personal Data Gets Into URLs

Nobody sets out to do this. It arrives through ordinary features.

Search queries deserve particular mention. People type names, medical terms, and account numbers into search boxes, and many sites put the query in the URL.

Where a URL Travels

Once a value is in a URL, it is written to:

• Your web server logs
• CDN and proxy logs
• Every analytics tool on the page, as the page path or location
• Session recording tools, as the page URL of the session
• Advertising pixels
• Error tracking tools, in the context of each error
• The visitor's browser history and bookmarks
• The referrer header, sent to any other site the visitor clicks through to, depending on your referrer policy
• Shared links, when the visitor copies the address
• Screenshots and support tickets

Many of these are third parties, each with its own retention and access controls. A deletion request now has a dozen places to chase.

For tokens, the risk is direct. A password reset token in a URL that reaches a third-party script or a referrer header can be used by someone else.

Why Masking Does Not Help

Session replay masking operates on the page's content: it replaces the text of inputs and marked elements before anything is sent. The URL is not page content. It is metadata recorded alongside every page view, by every tool.

So a site can have exemplary masking and still send an email address to five vendors on every load of an unsubscribe page.

The same care applies to anything you send deliberately. Event names, event properties, campaign parameters, and user attributes are all stored as provided. DeepSync's docs make this point about the identify call: whatever you pass is stored and visible in the dashboard, so send only what you would be comfortable having a teammate read.

How to Find It

1. Search your analytics page report. Look for @, email=, name=, phone=, token=, key=, and password.
2. Review query parameters. Export the distinct parameter names your site receives and read the list.
3. Check top pages for paths containing names or usernames.
4. Look at your site search report. Read a sample of the queries.
5. Follow your own emails. Click every link in your transactional and marketing emails and read the address bar.
6. Walk through flows that leave and return: login providers, payment, verification.
7. Search server logs with the same patterns.
8. Check what your forms use. A form using GET puts every field in the URL.

Do this once thoroughly, then after any change to email templates, authentication, or checkout.

How to Fix It

At the source

• Use POST for forms that contain personal data.
• Use opaque identifiers. /users/8f3a2c instead of /users/jane.doe.
• Put tokens in the fragment or exchange them immediately. Handle a reset or magic-link token on arrival, then redirect to a clean URL before other scripts run.
• Do not prefill forms from the query string. Look the data up server-side from an opaque reference.
• Keep customer identifiers out of campaign parameters (UTM guide).
• Submit site search by POST, or accept that queries are sensitive and exclude search pages from third-party tools.

As a safety net

• Clean the URL before analytics loads. Remove sensitive parameters with the History API so later scripts see a clean address.
• Set a strict referrer policy, such as strict-origin-when-cross-origin, so full URLs are not sent to other sites.
• Do not load third-party scripts on reset, verification, and similar pages.
• Configure parameter exclusion in tools that support it.
• Redact in logs where your infrastructure allows.

For what has already leaked

• Expire any exposed tokens.
• Ask vendors to delete affected data, or use their deletion tools.
• Record the incident and assess whether it must be reported under the laws that apply to you.

Key Takeaways

• URLs are copied into logs, analytics, history, and referrers.
• Masking protects page content, not the address.
• Search your reports for emails, names, and tokens.
• Fix it at the source with POST and opaque identifiers.

Conclusion

Personal data in URLs is the leak that survives every privacy review, because nobody looks at the address bar. Look at it.

Read about PII masking.