---
title: "Why URLs Leak Sensitive Information | LinkPilot Blog"
description: "URLs are visible to browsers, proxies, analytics, and referrer headers. Here's where they leak and how to design around it."
lang: en
json-ld: |
[
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"@id": "https://uselinkpilot.com/#software",
"name": "LinkPilot",
"applicationCategory": "BusinessApplication",
"operatingSystem": "Web",
"description": "LinkPilot is a secure link management platform for creating branded short links, tracking engagement, and sharing secrets with expiring, protected, self-destructing links.",
"url": "https://uselinkpilot.com",
"offers": [
{
"@type": "Offer",
"name": "Free",
"price": "0",
"priceCurrency": "USD",
"url": "https://uselinkpilot.com/pricing"
},
{
"@type": "Offer",
"name": "Pro",
"price": "29",
"priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"price": "29",
"priceCurrency": "USD",
"billingDuration": "P1M"
},
"url": "https://uselinkpilot.com/pricing"
},
{
"@type": "Offer",
"name": "Agency",
"price": "299",
"priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"price": "299",
"priceCurrency": "USD",
"billingDuration": "P1M"
},
"url": "https://uselinkpilot.com/pricing"
},
{
"@type": "Offer",
"name": "Enterprise",
"priceSpecification": {
"@type": "PriceSpecification",
"priceCurrency": "USD"
},
"url": "https://uselinkpilot.com/pricing"
}
]
},
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://uselinkpilot.com/#organization",
"name": "LinkPilot",
"url": "https://uselinkpilot.com",
"parentOrganization": {
"@type": "Organization",
"@id": "https://tetracorehq.com/#organization",
"name": "TetraCore",
"url": "https://tetracorehq.com/"
},
"logo": {
"@type": "ImageObject",
"url": "https://uselinkpilot.com/logo-512.png",
"width": 512,
"height": 512
},
"description": "LinkPilot is a secure link management platform for creating branded short links, tracking engagement, and sharing secrets with expiring, protected, self-destructing links.",
"sameAs": [
"https://x.com/uselinkpilot",
"https://www.linkedin.com/company/uselinkpilot",
"https://facebook.com/uselinkpilot"
]
},
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "LinkPilot",
"url": "https://uselinkpilot.com",
"potentialAction": {
"@type": "SearchAction",
"target": "https://uselinkpilot.com/blog?q={search_term_string}",
"query-input": "required name=search_term_string"
}
},
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://uselinkpilot.com"
},
{
"@type": "ListItem",
"position": 2,
"name": "Blog",
"item": "https://uselinkpilot.com/blog"
},
{
"@type": "ListItem",
"position": 3,
"name": "Why URLs Leak Sensitive Information",
"item": "https://uselinkpilot.com/blog/why-urls-leak-sensitive-information"
}
]
},
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://uselinkpilot.com/blog/why-urls-leak-sensitive-information#article",
"headline": "Why URLs Leak Sensitive Information",
"description": "URLs are visible to browsers, proxies, analytics, and referrer headers. Here's where they leak and how to design around it.",
"datePublished": "2026-05-26",
"dateModified": "2026-07-14",
"image": "https://uselinkpilot.com/logo-512.png",
"author": {
"@type": "Person",
"name": "W. Miller",
"worksFor": {
"@type": "Organization",
"name": "LinkPilot",
"url": "https://uselinkpilot.com"
}
},
"publisher": {
"@type": "Organization",
"name": "LinkPilot",
"url": "https://uselinkpilot.com",
"logo": {
"@type": "ImageObject",
"url": "https://uselinkpilot.com/logo-512.png",
"width": 512,
"height": 512
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://uselinkpilot.com/blog/why-urls-leak-sensitive-information"
}
},
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Is HTTPS enough to keep URL parameters private?",
"acceptedAnswer": {
"@type": "Answer",
"text": "HTTPS encrypts the URL in transit, but the URL is still logged in browser history, server access logs, and shared via Referer headers when the page links out. Encryption in transit doesn't make a URL secret."
}
},
{
"@type": "Question",
"name": "What about fragment identifiers (#)?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Fragments aren't sent to the server, which is why some end-to-end encrypted tools put the key in the fragment. They're still visible to browser extensions and any JavaScript on the page."
}
},
{
"@type": "Question",
"name": "Should I put a token in the path or the query string?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Neither is meaningfully more private. Both end up in the same logs and analytics. If the token must be in the URL, treat the whole URL as the secret and use one-time semantics."
}
},
{
"@type": "Question",
"name": "Do modern browsers still send the full URL in the Referer header?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Cross-origin, modern browsers default to strict-origin-when-cross-origin, which trims the referrer to just the origin. But same-origin requests still carry the full URL, a page can loosen the policy, and embedded webviews vary — so set Referrer-Policy: no-referrer explicitly on sensitive pages rather than relying on defaults."
}
},
{
"@type": "Question",
"name": "How long do URLs live in server logs?",
"acceptedAnswer": {
"@type": "Answer",
"text": "As long as the retention policy says — commonly weeks to months — and access logs are routinely shipped to log-aggregation services, so copies exist in systems the site owner doesn't directly run. Assume any URL that reached a server is stored in several places you can't enumerate."
}
}
]
}
]
---
[LinkPilot ](/)
[Features](/features)[Tools](/tools)[Blog](/blog)[Pricing](/pricing)[FAQ](/#faq)
Toggle theme [Sign In](/login)[Start free](/signup)
1. [Home](/)
2. [Blog](/blog)
3. [Security](/blog/category/security)
4. Why URLs Leak Sensitive Information
[Security](/blog/category/security)
# Why URLs Leak Sensitive Information
URLs are visible to browsers, proxies, analytics, and referrer headers. Here's where they leak and how to design around it.
By W. Miller · May 26, 2026 · 7 min read
A URL feels private because only the people you send it to should have it. In practice, a URL is one of the most-logged pieces of data on the web: it is written down, copied, and forwarded by systems that never asked your permission and that you cannot audit. Here's exactly where it leaks, and how to design links that survive it.
## The leakage surface
- **Browser history.** Every URL the user visits is stored locally and can sync to other devices — and to the browser vendor's sync service.
- **[HTTP](/glossary#http "Glossary: http") server access logs.** Most servers log the full request path and [query string](/glossary#query-string "Glossary: query string") by default. Anyone with log access has the URL.
- **Reverse proxies and CDNs.** Cloudflare, Fastly, your load balancer — all log the URL, each with its own retention policy.
- **Log aggregation pipelines.** Access logs rarely stay on one machine; they're shipped to centralized logging and monitoring services, multiplying the number of systems holding the URL.
- **Referer headers.** When the page links to a third-party resource, the browser can send the source URL in the `Referer` header. Analytics scripts, embedded videos, and ad pixels all receive it.
- **Browser extensions.** Extensions with "read browsing history" permission see every URL, including fragments.
- **Bookmark sync.** Bookmarked URLs sync across the user's devices and to the browser vendor's servers.
- **URL preview unfurlers.** Slack, Teams, iMessage, LinkedIn, and email clients fetch URLs to render previews — silently, the moment the message is sent.
- **Corporate proxies and email gateways.** Many organizations inspect, rewrite, and log every URL that crosses their boundary.
## What HTTPS does and doesn't protect
Worth being precise, because "the connection is encrypted" gets misread as "the URL is private."
[TLS](/glossary#ssl "Glossary: tls") encrypts the path and query string in transit: a network observer between the browser and the server cannot read `/reset?token=...`. What TLS does _not_ hide: the destination hostname (visible via DNS resolution and the TLS SNI field on most connections today), and anything at the endpoints — the browser still records the full URL in history, and the server still writes it to its access log. Encryption in transit protects the wire, not the two ends, and the two ends are where URLs leak.
## A worked example: one URL's life
Trace a single sensitive URL — say a reset link, `https://example.com/reset?token=8f3a91...` — from send to click:
1. **The mail provider** stores the message (URL included) indefinitely, and its security scanner may fetch the URL on delivery.
2. **The recipient's email gateway** rewrites and logs the URL, then fetches it again at click time.
3. **DNS** resolves `example.com` — the hostname (not the path) is now in resolver logs.
4. **The web server** writes the full request line to its access log. A default nginx/Apache "combined" format entry looks like:
```text
203.0.113.7 - - [14/Jul/2026:09:12:45 +0000]
"GET /reset?token=8f3a91... HTTP/1.1" 200 5123 "-" "Mozilla/5.0 ..."
```
5. **The [CDN](/glossary#cdn "Glossary: cdn") in front of it** logs the same URL with its own retention.
6. **The page's analytics script** records the page URL — query string and all — in a third-party system, unless explicitly configured to strip it.
7. **The browser** stores the URL in history and syncs it.
One send, seven copies, held by at least five organizations. None of this required an attacker — it's the web working as designed.
## Referer header in practice
If your secret reveal page links to any external resource (a CDN font, an analytics script, an embedded image), the browser may send the page's URL in the `Referer` header to that origin.
Modern browsers default to `strict-origin-when-cross-origin`, which trims cross-origin referrers to just the origin (`https://example.com/` rather than the full path). That's real progress, but not something to rely on: same-origin requests still carry the full URL, a page-level policy can loosen the default, and older clients and embedded webviews vary.
Two practical mitigations:
```html
```
```http
Referrer-Policy: no-referrer
```
The header version applies sitewide; the meta tag applies to the specific page. Use both for defense in depth — and better still, serve sensitive pages with **no third-party resources at all**, so there is nothing to send a [referrer](/glossary#referrer "Glossary: referrer") to.
## Path vs query vs fragment
Where you put a token in the URL changes who sees it:
Location
Sent to server?
In server logs?
In Referer?
In browser history?
Path (`/s/abc123`)
Yes
Yes
Policy-dependent
Yes
Query (`?token=abc123`)
Yes
Yes
Policy-dependent
Yes
Fragment (`#abc123`)
No
No
No
Yes
The [fragment](/glossary#fragment "Glossary: fragment") is genuinely different: per RFC 3986 it's processed client-side and never included in the HTTP request, which is why end-to-end encrypted paste tools put the decryption key there — the server literally never receives it. It's still not invisible: browser history, extensions, and any JavaScript running on the page can read it. Path versus query, by contrast, is a distinction without a privacy difference — both land in the same logs.
## The password-reset-token problem
Sensitive tokens in URLs are a recognized vulnerability class — CWE-598 covers exactly this: sensitive data in query strings ends up in logs, histories, and referrers regardless of transport encryption. It's why well-built password-reset flows never rely on the secrecy of the URL alone. They make the token **single-use**, **short-lived**, and **bound to a subsequent action** (setting a new password), so a token recovered from a log three weeks later is worthless.
That's the general lesson: you usually cannot keep a URL out of the logs, but you can make the logged URL worthless by the time anyone reads it.
## Designing URLs that are safe to leak
Assume every URL you mint will eventually surface somewhere unintended, and design so that it doesn't matter:
- **One-time consumption.** Burn the secret after the first successful read so a leaked URL is dead by the time it appears in someone's history.
- **Short expiry.** Bound the leakage window. A URL that worked for five minutes is worth far less than one that worked for a week.
- **Out-of-band passphrase.** Require a secret that was never in the URL. Now the URL alone — the only thing the logs have — is insufficient.
- **Separate fetch from reveal.** Serve metadata on `GET` and release the payload only on an explicit `POST`, so preview bots and scanners can't consume the secret.
- **No third-party resources on sensitive pages**, plus `Referrer-Policy: no-referrer` and ``.
- **Redact secret routes in your own logs.** In nginx, map the request URI before logging:
```nginx
map $request_uri $loggable_uri {
~^/s/ "/s/[redacted]";
default $request_uri;
}
log_format redacted '$remote_addr - $remote_user [$time_local] '
'"$request_method $loggable_uri" $status';
access_log /var/log/nginx/access.log redacted;
```
You control only your own logs — the CDN, proxy, and browser copies remain — which is exactly why the first three items on this list carry most of the weight.
## How this shapes secret links
This threat model is why LinkPilot's Secret Links work the way they do: the URL is treated as inevitably-leaked, so the URL alone is never enough. A `GET` returns only metadata; the payload requires an explicit `POST` reveal, optionally gated by a passphrase that's SHA-256 hashed client-side. Burned, expired, or revoked secrets return HTTP 410 with the payload irreversibly overwritten, reveal responses carry `Cache-Control: no-store`, and view events log a hashed IP under a daily-rotating salt rather than the raw address. And one candid limit, stated on the [security architecture](/security-architecture) page: this is not end-to-end encryption — the honest guarantees are short expiry, [burn-after-read](/glossary#burn-after-read "Glossary: burn-after-read"), and the out-of-band passphrase.
Try it free, no signup
### Burn-After-Read Secret
Share a message that destroys itself after one view.
[Open tool](/tools/burn-after-read-secret)
## Limits
URL design can't fix everything. It doesn't control what the recipient does after a legitimate read, it can't purge copies that third parties already hold, and it won't save a URL that carries personal data in plain sight — if a user's email address is in the query string, no expiry makes that unlogged. The durable rule: never put data in a URL that you'd need to delete later, because deleting a URL from everywhere it has been copied is practically impossible. Design URLs that are worthless when leaked instead.
## Related reading
- [How one-time secret links work](/blog/how-one-time-secret-links-work)
- [Link scanners and one-time secrets](/blog/link-scanners-and-one-time-secrets)
- [Self-destructing links](/self-destructing-links)
## Tools mentioned in this article
[
Burn-After-Read Secret
Share a message that destroys itself after one view.
](/tools/burn-after-read-secret)[
Free Secret Link Generator
Send encrypted, self-destructing messages securely.
](/tools/free-secret-link-generator)
## Frequently asked questions
### Is HTTPS enough to keep URL parameters private?
### What about fragment identifiers (#)?
### Should I put a token in the path or the query string?
### Do modern browsers still send the full URL in the Referer header?
### How long do URLs live in server logs?
## Run smarter links with LinkPilot
Tracking, UTMs, QR codes, AI insights, and white-label reporting — in one workspace. Free to start.
[Create your free account](/signup)
## Read next
[
Security
### OneTimeSecret vs Privnote vs Password Pusher: Which Should You Use?
A three-way comparison of the most popular secret-sharing tools — encryption, expiry, revocation, self-hosting, and where each one genuinely wins.
](/blog/onetimesecret-vs-privnote-vs-password-pusher)[
Security
### Is Privnote Safe? An Honest Security Assessment (2026)
Privnote's core mechanism works, but clone-site phishing, closed source code, and zero auditability are real risks. Here's a fair assessment and safer setups.
](/blog/is-privnote-safe)[
Security
### How to Send a Password Securely (Without Leaving It in Chat Forever)
The safest way to send a password is a one-time encrypted link that self-destructs after viewing. Here's every method ranked, with the trade-offs spelled out.
](/blog/how-to-send-a-password-securely)
On this page
- [The leakage surface](#the-leakage-surface)
- [What HTTPS does and doesn't protect](#what-https-does-and-doesnt-protect)
- [A worked example: one URL's life](#a-worked-example-one-urls-life)
- [Referer header in practice](#referer-header-in-practice)
- [Path vs query vs fragment](#path-vs-query-vs-fragment)
- [The password-reset-token problem](#the-password-reset-token-problem)
- [Designing URLs that are safe to leak](#designing-urls-that-are-safe-to-leak)
- [How this shapes secret links](#how-this-shapes-secret-links)
- [Limits](#limits)
- [Related reading](#related-reading)
LinkPilot
[About](/about)[Features](/features)[Pricing](/pricing)[For Agencies](/url-shortener-for-agencies)[Tools](/tools)[Blog](/blog)[Glossary](/glossary)[Compare](/compare)[Privacy](/privacy)[Security](/security-architecture)[Transparency](/transparency)[Terms](/terms)[GDPR](/gdpr)
[](https://x.com/uselinkpilot)[](https://www.linkedin.com/company/uselinkpilot)[](https://facebook.com/uselinkpilot)
© 2026 TetraCore. All rights reserved. · LinkPilot is [a TetraCore product](https://tetracorehq.com/)