Prevent Unlisted Share Links Leaking via Referrers and Logs

Table of contents

1. Why unlisted links leak in practice
2. Referrers: when the browser sends your URL elsewhere
3. Logs and analytics: where URLs get stored forever
4. Prefer path tokens over query strings
5. A hardened default for shared review pages
6. A pre-share checklist

Why unlisted links leak in practice

An unlisted share link is a *capability URL*: anyone who has it can use it. That is the defining property of a bearer token (possession is enough), and it’s why OAuth guidance warns about passing bearer tokens in page URLs.

So the goal is not “make the URL hard to guess” (you should), it’s also “make the URL hard to *accidentally copy* into places you don’t control”.

If you also need lifecycle controls, pair this with Expiry and Revocation: Make Unlisted HTML Links Safe to Share.

Referrers: when the browser sends your URL elsewhere

When a reviewer opens an unlisted link, the browser may include a Referer header on subsequent requests (images, scripts, CSS, fetch calls) depending on your Referrer-Policy. If the share URL contains sensitive information (like the share token itself), that information can leak to other origins through referrers.

Practical defaults for unlisted share pages and artifact viewers:

• Set a restrictive Referrer-Policy (commonly no-referrer, or at least a policy that won’t send the full URL cross-origin).
• Avoid loading third-party assets on shared pages (analytics, fonts, images) unless you’re confident you’re not sending referrers.
• Keep “review pages” focused on the review workflow, not a pile of external embeds.

If your workflow involves multiple outputs, a project index page should be a safe *link hub* (metadata + links) rather than another surface that executes arbitrary HTML. See Project Share Pages: One URL for a Multi-Artifact Handoff.

Logs and analytics: where URLs get stored forever

Even if you never leak via referrers, URLs tend to be copied into durable systems:

• reverse-proxy access logs
• application request logs (especially error logs)
• link shorteners and redirect services
• analytics event payloads (page URL, referrer, UTM tags)
• chat and issue tracker “link preview” fetchers

If the share token is in the URL, assume it can land in at least one of those places. OWASP calls out query strings specifically because they show up across logs and browser history.

Two practical mitigations:

1. Redact or minimize URL logging for public share routes (especially full-path logging).
2. Keep shared review pages self-contained so they don’t trigger cross-origin requests that create more logs.

If your artifacts may contain sensitive strings (API keys, signed URLs, IDs), also add a pre-publish scan; start with Scan and Redact Secrets Before You Publish HTML Artifacts.

Prefer path tokens over query strings

When you design share URLs, prefer a token in the path (like /s/<token>) over a token in the query string (like ?token=<token>).

Why this helps in practice:

• Many logging setups capture query strings by default; you have to opt out.
• People copy/paste and screenshot URLs; queries tend to be longer and get duplicated in more places (including “recent links” UIs).
• Security guidance for bearer tokens explicitly warns against putting tokens in URLs (including query parameters).

Path tokens can still leak, so treat this as “reduce risk”, not “solve security”. Combine it with expiry, revocation, and plan-based visibility defaults from /pricing.

A hardened default for shared review pages

A practical set of defaults for a shared artifact or project page:

1. Unlisted by default, with easy server-side revocation.
2. Restrictive Referrer-Policy so the browser doesn’t send the full share URL to other origins.
3. No third-party assets or analytics on the public share route.
4. noindex hygiene so search engines don’t index unlisted pages (useful, but not security).
5. If the artifact itself is untrusted HTML, keep it sandboxed and isolate it from your “index” UI.

When you automate publishing from CI, use the API docs. When the agent is deciding what belongs in the handoff bundle, use the MCP docs.

A pre-share checklist

Before you paste an unlisted URL into Slack:

• Does the page set an appropriate Referrer-Policy?
• Does the page avoid third-party embeds that might receive referrers?
• Are access logs and error logs redacting the share route URL where possible?
• Is there an expiry date, or at least a clear revocation path?
• Did you scan/redact secrets in the generated HTML source before publish?

If you’re iterating, resend a diff instead of a fresh link: use Compare so reviewers only focus on what changed.