Yes. Anything placed in a URL, including a path segment or query string, is routinely copied into web server logs, load balancer logs, proxy logs, browser history and analytics tools. Use opaque identifiers in URLs, send sensitive values in request bodies or headers, and keep query strings out of your logs by default.
Why URLs travel so far
A URL is not private data in transit between your user and your server only. It is metadata that many systems record because it is cheap and useful. A single page view can be written down by a CDN, a reverse proxy, the application server, a monitoring agent, a browser extension and any script on the page that reports the current location.
The HIPAA de-identification rule lists web URLs, IP address numbers and medical record numbers among the 18 identifiers that must be removed under the Safe Harbor method (45 CFR 164.514(b)(2)(i)). That list is about de-identifying datasets, not a definition of what to log, but it is a useful reminder that engineers often treat these values as harmless technical strings when they are not.
Examples of what goes wrong
- A search page with the query in the address, such as a patient name typed into a lookup.
- A password reset or invite link that carries an email address.
- A record view at a path that includes a medical record number.
- A referrer that shows the full previous URL to an external site.
Each of these writes patient information into places that were never designed to hold it.
What to do instead
- Use opaque identifiers, such as random UUIDs, in paths. Never use a record number or national ID.
- Send search terms and form values by POST, or in a body, not in the query string.
- Keep tokens out of URLs where you can. If a one time link must carry a token, make it short lived and single use.
- Set a referrer policy so full URLs are not passed to other sites.
- Configure access logs to drop or mask query strings, and check the proxy and CDN too, not just the app.
- Check what any analytics or error tracking script captures from the current location.
Number 5 is the one teams forget. The application can be clean while the load balancer still logs every query string.
How to test it
Pick five key screens in the app. Perform a realistic action on each with a test account, then search every log layer for the test values. Check the web server, the proxy, the CDN, the application and any third party monitoring. Anything you can find by searching is a finding.
Record what you changed and when. That record is useful evidence of a working control. This is general engineering guidance, not legal advice.
Where Safeguard fits
Safeguard can scan your code and dependencies and enforce policy in pull requests, so a library that logs full request data by default can be caught at intake. Deciding which URL patterns are allowed stays with your team. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is HTTPS enough to protect a URL?
HTTPS protects the URL on the wire between browser and server. It does not stop the server, proxies, CDNs, scripts and browsers from recording it.
Are opaque IDs always safe?
They are safer, provided they cannot be guessed and access is checked on every request. An opaque ID without an authorization check is still an exposure.
Sources
Last reviewed: 19 October 2026.
