Security & Privacy

Auditing URLs Before You Share Them: Catching Tracking Tokens, API Keys, and Credential Leaks

Published:  ·  15 min read
Audit shared links for credential leaks

You paste a link into a shared Slack message and move on. Ten minutes later someone flags it: the URL carries an active API key visible to everyone in that channel, archived in your chat history, and cached in every search index that touched the conversation. That key might already be compromised, and you had no idea it was there. It happens faster than you think, and the URLs that leak credentials are rarely the ones you expect.

Every URL you share breaks into components, and several of those components routinely carry sensitive data. Query parameters hold OAuth access tokens, session identifiers, and API keys because developers treat them as convenient storage. Fragments can contain temporary authorization state for OAuth flows. The pathname might expose internal service names, user IDs, or version numbers that reveal your stack. Most people read URLs as opaque strings, but each one contains data worth inspecting. CapyToolkit’s URL Parser that decomposes every link into its constituent parts lets you inspect each component before the URL leaves your control. This guide walks through a repeatable pre-share audit workflow you can run in under 30 seconds, plus the sanitization steps that follow once you have identified what needs to be removed.

What the URL Components Actually Reveal

Most people treat URLs as opaque strings. The browser’s URL constructor breaks any valid URL into named properties, each one a potential leak point. According to the MDN URL API reference, the native constructor exposes href, origin, protocol, hostname, port, pathname, search, and hash.1 CapyToolkit’s URL Parser goes further by deriving additional structured components like subdomain, domain, and TLD from the hostname, giving you a full decomposition in a single view. Understanding what each component can reveal is the first step in spotting leaks before you share a link.

Scheme and protocol signals

An http URL transmits the entire request path and query string in cleartext, readable by any network observer between you and the server. An https URL encrypts the request path, query parameters, headers, and body over the TLS tunnel, hiding them from on-the-wire eavesdroppers. The domain name remains visible through SNI2, and the full URL persists in your browser history, client-side extensions, upstream server logs, and HTTP Referer headers when you navigate away. Mixed-content warnings appear when an https page loads scripts or images over http, silently downgrading the security of those individual resources.3 Protocol-relative URLs starting with // borrow the current page’s scheme, so a link shared from an http page inherits that insecure scheme regardless of what the target domain normally serves.

Hostname anatomy: subdomain, domain, and TLD

The hostname splits into subdomain, domain, and TLD using simple dot-splitting. Internal subdomains like api.internal.company.com expose organizational structure and service naming conventions. Staging and development environments at staging.example.com or dev.example.com reveal your deployment pipeline and testing practices. Country-code TLDs and multi-part suffixes like .co.uk or .com.au indicate regional hosting choices. The URL Parser displays all three components separately, so you can review each layer before sharing a link that might reveal more about your infrastructure than you intend.

While hostname configurations reveal your hosting infrastructure, the query parameters and fragment identifiers present a far more immediate threat to credential security.

Query string and fragment: where credentials hide

The query string holds parameter pairs that often include access tokens, password reset links, and session identifiers. The fragment identifier after the # never reaches the server, but browsers store it and many single-page applications use it for routing state and OAuth authorization tokens. When you paste a URL into a ticket or message, both sections travel in plain sight. The URL Parser shows the search and hash properties separately, making it easy to spot content in either location that should not be there.

Query Parameters as Credential Leakage Vectors

Query parameters are the single most common vector for accidental credential exposure in shared URLs. Because the browser’s built-in URLSearchParams API decodes percent-encoded values automatically, both legitimate users and anyone downstream see the same readable values. Note that URLSearchParams also decodes raw plus signs as spaces to match form-urlencoded specifications, which silently corrupts base64 payloads and JWTs that use the + character.4 When you rely on browser-based tools that process everything locally, you avoid the risk of sending a URL with embedded credentials through an additional server hop. Long encoded values like JWTs and base64 blobs don’t break the layout. CapyToolkit’s URL Parser uses this API directly, showing each parameter in a scrollable grid that handles values of any length without stretching the page.

Recognising common credential parameter patterns

The credential parameter names follow a recognizable pattern across APIs, frameworks, and internal tools. These names appear consistently across services because they describe what the parameter does rather than what application created it. When you scan a URL for these patterns, you are checking for function, not brand, which makes the scan reliable across any service:

  • access_token and token: active OAuth and API bearer credentials. Treat these as highly sensitive.
  • api_key and key: service-level identifiers that grant programmatic access to APIs.
  • password and secret: plain-text credentials or raw application secrets. Immediate red flag.
  • session_id and session: active session tokens that tie directly to a logged-in user.
  • auth and bearer: authorization headers pasted into query form by impatient clients.

When you paste a URL into the URL Parser, the Query Parameters section surfaces every name-value pair in the grid. The browser’s URLSearchParams API decodes percent-encoded values automatically, so %20 and %2F appear readable without any extra decoding step. A scan for any name matching this pattern takes under ten seconds. The values next to those names are what you need to remove before sharing.

How OAuth tokens end up in query strings

The OAuth 2.0 implicit flow originally returned tokens via the URL fragment, which keeps them out of the HTTP request sent to your application’s redirect server during the callback handshake.5 But misconfigured authorization servers still return tokens as query parameters instead. When a user copies the URL from the browser address bar after an OAuth callback, they are copying a live access token. That token remains valid until it expires or is revoked, and anyone who receives the shared URL can use it immediately. Validating redirect URIs with exact-match rules is one defense against this pattern, since it prevents attackers from injecting their own collection endpoint.

URL shorteners and redirect chains don’t just obscure the destination. They can change the scheme, strip parameters, or add tracking identifiers at each hop. Following a redirect chain reveals the final destination and any intermediate modifications, which matters when the original URL contained credentials that may or may not survive the redirect. The URL Parser shows you exactly what is in the URL you pasted, so you can audit the parameters before clicking through. If you rely on browser-based tools that process everything locally, you avoid the risk of sending the original URL through an additional server hop while inspecting it.

How bit.ly and t.co modify your query parameters

Some URL shorteners preserve query strings faithfully; others drop or rewrite them. A shortened link to an API endpoint with ?token= may arrive at the destination without that parameter, or the shortening service logged it before forwarding. The redirect server sits between the sender and the destination, giving it full visibility into every parameter in the original URL. Tracing short URLs and redirect chains programmatically lets you see the full path a shortened link takes and whether the original query string survives each hop.

When a redirect silently strips credentials

HTTP 301 and 302 redirects can carry the original query string forward, but some server configurations strip it entirely. If you shared a URL with ?key= and the redirect drops it, the recipient gets a working link but the original credential never reached the destination. It was captured by the redirect server instead. Browsers block client-side code from tracing redirect chains due to CORS, so checking where a shortened link ultimately lands requires clicking through or using a dedicated network utility. Audit the parameters in the original URL before you follow the redirect.

Redirect chains can strip parameters to secure your coordinates, but marketers and platforms use the query string to append tracking identifiers that follow your links across the web. A URL that survives a redirect intact still carries every UTM parameter, fbclid, and gclid that was in the original. The redirect itself is not the problem; the baggage that travels through it is. Auditing the parameters before you share catches both the credentials that get stripped and the tracking that survives.

UTM Parameters and Tracking Tokens That Follow You Across Sites

Ad-tech platforms design UTM parameters for marketing attribution, but they persist in shared URLs long after the campaign ends. A URL shared weeks after a newsletter campaign still carries the original utm_source, utm_medium, and utm_campaign values into contexts where they serve no purpose. This tracking follows you. For internal links shared between team members, those values reveal marketing strategy and audience targeting choices that don’t belong in a support ticket or project brief. The platform-specific tracking identifiers like fbclid and gclid compound this problem by adding viewer-specific data that persists across shares. The five standard UTM parameters utm_source, utm_medium, utm_campaign, utm_term, and utm_content paint a detailed picture of how someone found the link.6 Beyond UTM, platforms add their own tracking identifiers: Facebook’s fbclid, Google’s gclid, and TikTok’s ttclid. These parameters identify the viewer and their click path, turning a shared link into a tracking device. Stripping them before sharing removes the trail without affecting the destination page’s functionality.

The five standard UTM parameters and what each reveals

The five standard UTM parameters each serve a specific attribution role. Utm_source identifies the referring platform, utm_medium the channel type such as email or social, utm_campaign the specific promotion, utm_term the paid search keyword, and utm_content the A/B variant or creative version. Together they create a complete attribution record that persists in the URL long after the marketing campaign has ended. Extracting UTM parameters from URLs lets you read and validate these values programmatically, but the simpler approach for pre-sharing is to strip them entirely unless the recipient needs the attribution data.

Building a Pre-Share URL Audit Checklist

A 30-second pre-share audit catches the most common leaks before they reach a colleague, ticket, or public channel. The process uses CapyToolkit’s URL Parser to decompose the URL, then checks each component against a short list of risk patterns. The checklist takes under half a minute and catches the vast majority of accidental credential leaks in shared links. For sensitive contexts like OAuth redirect URIs and API endpoints, parsing and validating OAuth redirect URIs provides deeper validation, since the OAuth 2.0 specification requires exact-match rules on the redirect URI to prevent open redirect attacks.5

What a 30-second audit catches

The audit catches the leaks that matter most: credentials in query strings, tokens in fragments, internal infrastructure in hostnames, and tracking parameters that follow the recipient across sites. It does not catch every possible leak, but it catches the ones that happen most often in daily workflows. The URL Parser’s component grid gives you a structured view of every URL part, so you can review each one systematically rather than scanning the raw string for suspicious patterns.

The five-step parameter scan

To systematically audit a URL before sharing it, walk through these five checks in order:

  1. Paste the URL into the URL Parser and check the Query Parameters section for any parameter name matching credential patterns such as token, key, secret, session, or auth.
  2. Inspect the pathname for embedded user IDs, resource identifiers, or internal naming conventions that reveal your stack.
  3. Check the fragment for OAuth state tokens or temporary identifiers that should not persist in a shared link.
  4. Verify the scheme is https. An http URL transmits all query parameters in cleartext, making them visible to any network observer.
  5. If the URL was shortened, inspect the original URL for sensitive parameters before following the redirect, and audit the final destination after you land on it.

Verifying the final destination

A shortened URL resolves to a different destination than what appears in the short link. Before sharing a shortened link, verify that the final destination matches your expectation and that the intermediate servers did not strip or log any sensitive parameters along the way. Browsers block client-side code from programmatically tracing redirect chains due to CORS, so the safest approach is to audit the parameters in the original URL before clicking through, then verify the final landing page after the redirect completes. Securing URLs against SSRF and open redirects covers the validation patterns that prevent these attacks in web applications, and the same principles apply when auditing shared links.

Sanitizing URLs Before They Leave Your Control

Once you have identified sensitive parameters, removing them before sharing is straightforward. Strip the query string entirely, replace it with only the parameters needed for the destination to function, or use a URL sanitization approach that preserves legitimate parameters while dropping the sensitive ones. Because the recompiled URL must still resolve to the same destination, always verify the cleaned version loads correctly before sending it. A sanitized URL that breaks the destination defeats the entire purpose of sharing. By producing a canonical form, you generate a minimal, clean link that preserves destination functionality without carrying unnecessary tracking baggage. For OAuth redirect URIs specifically, exact-match validation rules mean that even small modifications to the redirect URL can break the flow or open SSRF vectors, as documented in OWASP’s SSRF guidance.

Removing tracking parameters without breaking the destination

Not all query parameters are sensitive. Page identifiers, search queries, and content filters are often legitimate and required for the destination to function correctly. Stripping a search parameter from a product page URL might break the filtered view the recipient expected to see. The URL Parser’s parameter grid lets you selectively remove only the tracking parameters such as utm_*, fbclid, and gclid while preserving the functional ones. Each parameter has a remove button, and the Modified URL field below the grid updates in real time as you edit. After removing the sensitive parameters, the recompiled URL appears ready to copy.

Canonicalizing URLs for safe sharing

URL canonicalization means producing one consistent, minimal form of a URL. For sharing, this means stripping tracking parameters, normalizing the scheme to https, removing the fragment if it carries state, and using the domain without www unless required by the server. The canonical form is the safe form because it eliminates unnecessary variations that could leak information or trigger different server behavior. Understanding URL canonicalization helps you produce it consistently across different URL patterns and edge cases.

When a Clean URL Still Isn’t Enough

A clean URL only protects against leaks in the link itself. The page it leads to can still collect browser fingerprint signals, and the link text in your message or email can carry metadata through automatic preview generation. The pre-share audit workflow covers the URL itself, but the destination layer requires a separate check. The destination page might still collect canvas hashes, WebGL renderer strings, audio context fingerprints, and font enumeration data.7 If you are sharing a link that leads to a page where recipients will log in or interact with sensitive content, running a browser fingerprint audit gives you a clear picture of what the recipient’s browser will reveal about itself.

The link text in your message or email carries its own metadata risk. Some email clients and chat platforms generate link previews that fetch the destination page and extract Open Graph tags, page titles, and metadata. That preview can reveal context about the destination that you did not intend to share. Consider whether the page title or description would be appropriate in the context where you are sharing the link.

For shared files, EXIF metadata in images or documents can reveal device information, timestamps, and GPS coordinates.8 An image pasted into a Slack thread carries its full EXIF payload unless you strip it first. When your workflows require protection beyond standard URL hygiene, combining your link auditing with EXIF metadata stripping and browser fingerprint checks closes the gap between what the URL reveals and what the destination page collects.

Sources
  1. 1.

    WHATWG, “URL Standard,” url.spec.whatwg.org, accessed July 2026. https://url.spec.whatwg.org/

  2. 2.

    Cloudflare, “What Is SNI? How TLS Server Name Indication Works,” cloudflare.com, accessed July 2026. https://www.cloudflare.com/learning/ssl/what-is-sni/

  3. 3.

    Mozilla Developer Network, “Mixed content,” developer.mozilla.org, accessed July 2026. https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content

  4. 4.

    Mozilla Developer Network, “URLSearchParams,” developer.mozilla.org, accessed July 2026. https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams

  5. 5.

    D. Hardt, Ed., “The OAuth 2.0 Authorization Framework,” RFC 6749, IETF, October 2012. https://www.rfc-editor.org/rfc/rfc6749

  6. 6.

    Google, “Collect campaign data with custom URLs,” support.google.com, accessed July 2026. https://support.google.com/analytics/answer/1033863

  7. 7.

    web.dev, “Fingerprinting,” web.dev, accessed July 2026. https://web.dev/learn/privacy/fingerprinting

  8. 8.

    “Exif,” Wikipedia, accessed July 2026. https://en.wikipedia.org/wiki/Exif

More in Security & Privacy