The Referrer Problem: How Secret URLs Can Leak (And How to Avoid It) 🧭

A practical guide to URL referrers, how secret links can leak via analytics and third‑party requests, and how Bitburner avoids it.

Secret URLs feel safe, but they can leak in places you don’t expect. One of the most common hidden leaks is the referrer header. It sounds technical, yet it is simple: when you click a link or load an image, browsers often send the page URL to the next request. If your secret is inside that URL, it can leak.

This post explains the referrer problem in plain language and how to avoid it. If you want to share secrets safely, you can use Bitburner here: bitburner.vberkoz.com.

What is a referrer, in human words 🧠

When your browser loads a new page or a resource, it may include a header called Referer (yes, it is misspelled in the standard). This header tells the next site where you came from. It can include the full URL, which is the problem for secret links.

Example:

You open a secret link.
The page loads a third‑party analytics script.
The request to the analytics server includes a referrer with the full URL.

If the URL contains a secret token, it might be visible to that third party. That is the leak.

Why secret URLs are risky by default ⚠️

Secret URLs are often used as access tokens. If someone gets the URL, they have access. So a leak of the URL is basically a leak of the secret.

Many products forget this. They load external scripts, images, fonts, or analytics on the secret page. Each external request is a chance to send the referrer.

The risk is not just “hackers”. It can be:

analytics providers,
CDN logs,
error tracking tools,
ad or pixel services,
third‑party fonts and icons.

Any of these can collect the full URL unless you prevent it.

A simple scenario (how the leak happens) 🕳️

Imagine this:

You open https://example.com/secret/ABC123.
The page loads https://analytics.com/pixel.js.
The request to analytics includes the referrer: https://example.com/secret/ABC123.

Now the analytics provider has your secret token in their logs. This is not theoretical. It happens in the wild, all the time.

Why fragments are safer, but not perfect 🧩

If the secret is in the URL fragment (#), browsers do NOT send it in referrer headers. This is good. It means a URL like:

https://bitburner.vberkoz.com/#<id>:<key>

does not leak the fragment in Referer. The server sees only the base URL. This is one reason Bitburner keeps the key in the fragment.

But fragments are not magic. If you copy the full URL into analytics tools or logs, the fragment can still leak. So you should treat the full link as sensitive.

Referrer policies: the main defense 🛡️

Browsers allow you to control referrer behavior with the Referrer-Policy header. Common safe settings are:

no-referrer (send nothing),
strict-origin (send only the domain, no path or query).

For secret pages, the safest is no-referrer. That prevents the browser from sending the full URL to any third‑party requests.

Bitburner uses a strict referrer policy on secret pages to reduce this leak vector.

Why analytics on secret pages is risky 📊

Analytics are great for marketing pages. But for secret pages, analytics can be dangerous if they collect full URLs.

If you must track usage, use server‑side metrics without the full URL, or store only counts. Never log the raw secret link.

This is a cultural issue too: growth data is not worth leaking secrets.

Shorteners and redirects can leak too 🔗

URL shorteners often log the full destination URL so they can provide click stats. If your secret link goes through a shortener, you may be giving that service a copy of your token. Redirect chains can also leak referrers to intermediate services.

For secret links, avoid shorteners and avoid unnecessary redirects. Share the direct link and keep the path as short as possible. This is a small change, but it removes an entire layer of potential logging.

Query params are the worst place for secrets 🚫

If your secret is in a query parameter (?token=...), it will almost always be leaked via referrer. That is why it is better to avoid secrets in query strings.

Fragments are safer, because browsers do not send them to servers or as referrers.

So if you are building a secret sharing system, never put the key in a query param. Use the fragment or a short‑lived token on the server side.

What users can do to reduce referrer leaks 👥

Even if a site is not perfect, users can reduce risk:

open secret links in private windows,
avoid browser extensions that inject scripts,
do not paste secret URLs into other tools,
close the tab after use.

These habits reduce leaks in practice.

How Bitburner avoids the referrer problem ✅

Bitburner uses several strategies:

the key is in the fragment, not query,
secret pages are simple and avoid third‑party scripts,
referrer policy is strict,
the server never needs the key.

This combination makes referrer leaks much less likely. It is not perfect, but it is a strong, practical design.

Why this matters for teams and companies 🏢

In team environments, secrets are often shared quickly. A single leak can lead to production access or data loss.

Referrer leaks are “silent” — nobody notices until it is too late. That is why it is important to design systems that avoid them by default.

A quick checklist for builders 🧰

If you are building any tool with secret URLs, check:

Are secrets in query params? Move them to fragments.
Do you load third‑party scripts? Remove them from secret pages.
Do you set Referrer-Policy? Use no-referrer.
Are you logging URLs? Strip tokens before logging.

These steps are simple yet powerful.

SEO-friendly summary for quick readers 📌

Secret URLs can leak through the HTTP Referer header when a page loads third‑party resources or analytics. If the secret is in the URL path or query, it may be sent to external services. Using URL fragments, removing third‑party scripts, and setting a strict Referrer-Policy prevents most leaks. Bitburner follows this approach to keep secret links safer.

Final thoughts ✅

The referrer problem is a hidden but real risk. It does not require hackers — it can happen by normal web behavior.

If you share secrets, choose tools that avoid referrer leaks by design. If you want a practical option, use Bitburner: bitburner.vberkoz.com.