Overview
This check scans the final page URL of every crawled page for clear-text personal identifiers (email addresses, usernames, or checkout parameters) appended directly into the URL rather than transmitted through a secured mechanism.
Note: This guide is provided for informational purposes only and does not constitute legal advice. Consult qualified legal counsel regarding your organization's specific GDPR compliance obligations.
Why it is important
A clear-text identifier embedded in a URL flows directly into server logs, browser history, referrer headers, and every downstream analytics platform that receives the page URL as a matter of normal operation and this violates both the data minimization principle (Article 5(1)(c), which requires collecting only what's necessary through the appropriate channel) and the security-of-processing obligation (Article 32), since a URL is one of the least secure channels available for transmitting personal data.
Implementation
Create an Authenticated Audit and run it. The Authenticated audit is far more likely to surface personal information in the URL. Then create Journeys that replicates high-risk flows, such as password reset, email click-through links, and checkout redirects. Pro-tip: You can create these Journeys with the ObservePoint MCP Server.
Connect an AI agent to the ObservePoint MCP Server. Any agentic harness that supports MCP will work e.g. ChatGPT, Claude, Microsoft Co-Pilot Agents, Cursor, etc.
Ask the agent to review the URLs from your latest Audit and Journey runs for suspicious personal data, such as email addresses, usernames, names, phone numbers, or checkout parameters and to consider common encoding patterns (this is why we are recommending MCP Server).
For example: “Review the page URLs in my latest audit and Journey runs. List any URL parameter that looks like personal data, and explain why. Consider that some personal data may be encoded in the URL.”
Review what the agent flags. For each URL, note the parameter and the value pattern, then confirm that it really is personal data and not a harmless ID.
Remediation
For remediation, check the following steps:
For each flagged URL pattern, trace it to the originating link, redirect, or form submission. Password-reset links and email-marketing click-through URLs are the most common source, since they frequently embed an identifier or token directly in the URL for implementation convenience.
Redesign the flow to pass a secure, single-use, opaque token that maps to the identifier server-side, rather than embedding the actual personal data value in the URL itself, or move the parameter into a POST body or secure session mechanism where the flow allows it.
Re-run the agent check against a fresh audit run and the corresponding Journeys after remediation, and confirm with the analytics or logging team that historical instances have been addressed as part of the broader data-handling review.
Conclusion
Because URL-based PII leakage propagates silently to systems outside your direct control the moment the URL is generated, this check works best run continuously against both the standard crawl and any Journey that replicates identifier-bearing flows like password resets or checkout redirects.