PII in URL

What Is PII in URL?

Treating the URL as a private data channel is one of the most common privacy bugs in web applications. A URL travels through a long list of trust boundaries the application does not control: browser history, server and CDN access logs, the Referer header sent to every third-party asset that loads on the resulting page (analytics, fonts, payment SDKs, chat widgets), link-preview unfurlers in messaging apps, screen-recording tools, and any caching proxy on the request path. Anything sensitive in the URL is sensitive in all of those places too. This exercise puts you on both sides. As Bob, a data broker who profits from other people's information, you sign up a throwaway account on Westmark Industrial's vendor portal, request an account-verification link, and watch the browser's address bar reveal a URL that carries email, date of birth, and SSN-last-four in its query string. One link exposes Bob's own test data, and the same pattern leaks the personal data of every real customer who verifies, through referrer logs an attacker can simply buy. As Alice, the engineer who owns the verification service, you catch a data-loss alert, open the link-generator handler, see the identifiers assembled into the URL, and ship the fix: an opaque server-side token in place of the personal data, proven clean by re-running the flow. The exercise closes with quiz questions on why HTTPS does not protect URL contents from these leak transports, why encoding the data is not a fix, and what the right replacement shape looks like.

What You'll Learn in PII in URL

• Recognize that the URL is a public-ish identifier that crosses many trust boundaries, browser history, access logs, Referer headers, link unfurlers, screen capture
• Understand that HTTPS protects the URL in transit but does not stop it from being logged or forwarded by intermediate parties
• Apply the opaque-token rewrite: replace PII in URLs with a short-TTL random token that resolves server-side to the user
• Recognize that email, date of birth, and SSN-last-four together form an identity-verification (KBA) triplet an attacker can harvest at scale from bought referrer logs
• Audit every email-link / SMS-link generator (verification, password reset, magic login, share invite) for the same anti-pattern

PII in URL — Training Steps

1. Find the verification flow

   Bob has been probing Westmark Industrial's public vendor portal, looking for anything it leaks. Its account-verification step catches his eye: it emails a link to confirm the account. Bob signs up with a throwaway inbox he controls and junk identity details, so he can watch exactly what that verification link looks like. He starts on the request page.

2. Request a verification link

   Run the flow the way a real user would: enter the throwaway address and send the request. The portal takes it and queues a verification email to that inbox.

3. Open the verification email

   The verification email lands in Bob's throwaway inbox. He opens it and clicks the link, exactly the way a real user would. The browser is open right beside the inbox.

4. See the PII in the address bar

   Bob clicked the link, and it opened in the browser. This is the exact shape of every verification link Westmark emails. Bob does not need to break into anything now. He just needs the places these URLs pile up.

5. Harvest the referrer logs

   Bob is a data broker, not a hacker. He never sends a single request to Westmark. Instead he buys a month of referrer logs from an analytics reseller, the kind of vendor whose tracking tag sits on Westmark's verify page and quietly records the full referring URL of everyone who loads it. He opens a terminal next to the browser and greps that feed for the verification links.

6. Knowledge check

   Bob now holds this for thousands of people. Think about what those three fields actually are.

7. A privacy alert lands

   You own Westmark's account-verification service. Overnight, the data-loss monitor flagged the links it sends and emailed you the finding. Read what it caught, then open the code.

8. Open the link generator

   The handler that builds and emails the verification link is what you need to change. Open it and look at how it assembles the URL.

9. Spot the leak

   The handler pastes the account's email, date of birth, and SSN fragment straight into the query string, then emails the resulting link. There is no token and no indirection: the URL itself is the personal data.

10. Knowledge check

    You have seen where the data goes and the lines that put it there. Lock in why the URL is the wrong channel.