Remove sensitive data from URL query parameters

30 min Impact: medium Effort: medium ✓ Scan-verified — no manual checkbox

Sensitive information — session tokens, passwords, personal data — passed as URL query parameters ends up logged in browser history, server access logs, and analytics tools, and gets sent to any third party your page loads via the Referer header when a visitor clicks an outbound link.

Tokens, API keys, and passwords passed as ?token=... in a URL end up in browser history, server logs, and any analytics tool watching page views — all in plain text, all outside your control.

The full picture

Sensitive data included in URL query parameters creates several genuine, distinct exposure risks beyond the immediate page it appears on — URLs frequently get logged by web servers, appear in browser history, get included in referrer headers sent to other sites when a visitor navigates away, and can even be inadvertently shared when a visitor copies and shares a URL without realizing sensitive data is embedded within it.

The genuine risk here compounds across each of these exposure points — server logs containing sensitive URL parameters represent a real data-retention risk if those logs aren't appropriately secured, referrer header leakage discussed elsewhere in this security work can transmit this sensitive data to third-party sites, and browser history represents a persistent, local record of this sensitive information on a visitor's device.

Common categories of data that shouldn't appear in URL parameters include authentication tokens, personally identifiable information, and any data whose exposure through any of these described channels could cause genuine harm or privacy violation — this data belongs in request bodies or secure headers, not in the URL itself, which is inherently more exposed across multiple systems and contexts.

Remediation requires genuinely reviewing your actual application's URL structure and identifying any instances where sensitive data currently appears in query parameters, then restructuring the relevant functionality to transmit this data through more appropriately secured channels — this may require genuine application-level changes beyond simple configuration adjustment, depending on how deeply this pattern is embedded in your existing application architecture.

How to fix it

1

Audit your URLs for sensitive parameters

Look for anything like ?token=, ?password=, ?ssn=, ?email= in your site's actual URLs — check password reset links and any account-related flows specifically.
2

Move sensitive data out of the URL

Use POST request bodies, HTTP-only cookies, or short-lived server-side session references instead of putting the sensitive value directly in the URL.
3

For one-time-use tokens (like password resets) that must be in a URL

Make them single-use and short-lived, and set Referrer-Policy: no-referrer specifically on that page so the token doesn't leak via the Referer header if the user clicks an outbound link.

Common mistakes

Password reset links are the most common legitimate case where a token has to be in the URL — the fix there isn't removing it, it's making it single-use, short-lived, and protected by a no-referrer policy on that specific page.

How you'll know it's done

No passwords or long-lived session tokens appear directly in URLs; any necessary short-lived tokens are single-use and protected by a no-referrer policy.

H.I.V.E. checks this automatically

Fix it, then re-scan — the check confirms itself. No manual checkbox, the scan is the truth.

Run this check in H.I.V.E. →