Overview
This check scans the final page URL of every crawled page for patterns matching personal information (email addresses, phone numbers, or known account/customer ID formats) passed as query string parameters rather than in a secured request body.
Note: This guide is provided for informational purposes only and does not constitute legal advice. Consult qualified legal counsel regarding your organization's specific CCPA/CPRA compliance obligations.
Why it is important
Personal information passed in a URL query string is written to server logs, browser history, referrer headers, and every third-party analytics or advertising tool that receives the page URL as part of its normal tracking behavior. It is a silent but serious form of personal information leakage, and one of the easiest issues for a regulator or independent researcher to spot simply by inspecting a browser's address bar or history.
Implementation
Run a full-site Audit and apply a regex filter against the page URL for common PI patterns (email, phone, known ID formats).
Check the pre-built ObservePoint report for Personal Information in URL Query Parameters.
For each flagged URL, trace it to the originating link or redirect (password-reset and email-campaign click-throughs are the most common source) and supplement with a Journey that replicates those specific flows, since a standard crawl often won't surface them.
Remediation
For remediation, follow the next steps:
For each flagged URL pattern, trace it back to the originating link or redirect: password-reset and email-marketing click-through links are the most common source, since they frequently embed a token or identifier directly in the URL for convenience.
Redesign the flow to pass the identifier via a secure, single-use token that maps to the PI server-side rather than embedding the PI value itself, or move the parameter into a POST body / secure session mechanism where the flow allows it.
Re-run the regex-filtered Pages report and the corresponding Journey after remediation, and check server and analytics logs retroactively to determine whether historical leaked URLs need a broader data-handling review.
Conclusion
Because URL-based PI leakage happens silently and propagates to systems well beyond your own control the moment the URL is generated, this check is best run continuously against both the standard page crawl and any Journey that replicates identifier-bearing flows like password resets or email campaigns.