Privacy and preparation
Share links and access tokens in records: the doors still open
By SourceX Editorial · Updated
Short answer
Shared links in tickets, emails and chats are a security risk because many still work: anyone-with-the-link documents, password reset and login links, signed storage URLs and meeting links with passcodes. Before an export leaves the company, find every link that carries access, replace it with a typed placeholder, and revoke the live ones where they were created.
Key takeaways
- A URL can be a credential: if opening it grants access without a login, treat it like a password.
- Replacing a link in the export is not enough; revoke or expire it at the source.
- Do not test a link by opening it, because opening it is an access event and may consume it.
- Secret scanners find keys and tokens but need custom rules to catch share links.
- Keep the link's type as a placeholder, because knowing a file was shared is useful context.
Which links in business records still grant access?#
A link grants access when the URL itself carries the permission. That covers links with a token, signature or key in the path or query string, and links to resources set to open for anyone who has the address. Links to public web pages do not matter; links that skip a login do.
Every system that sends email or hosts files produces some of these. The table lists the common types, where they turn up in exports, and whether they tend to expire on their own.
Software companies have an extra category: links into their own product. Support agents paste admin console links, impersonation or login-as links, and one-time setup links into tickets while helping customers. Whether those still work depends on how your application issues them, so the engineering team, not the privacy reviewer, should judge them.
| Link type | Where it shows up | What it opens | Expires on its own? |
|---|---|---|---|
| Anyone-with-the-link file shares | Tickets, email, chat, project notes | Files and folders in cloud drives | Often not, unless someone set an expiry |
| Password reset and email verification links | Help desk replies, notification emails | Account recovery | Usually, but not always after use |
| Magic login and workspace invite links | Onboarding emails, CRM sequences | An account or workspace | Varies by product |
| Signed or presigned storage URLs | Logs, error reports, support attachments | A stored object | Yes, though some are issued with long lifetimes |
| Customer portal links for quotes, invoices and payments | Estimate and invoice emails | Customer account pages | Often not |
| Meeting links with a passcode in the URL | Calendar invites and chat | A meeting room | Recurring rooms may stay open |
| API keys and bearer tokens pasted as text | Developer support tickets, engineering chat, error logs | Customer or internal systems through their APIs | Not until revoked or rotated |
| Webhook and integration URLs | Engineering tickets and chat | Posting into a channel or system | Not until rotated |
Why share links slip past a privacy review#
Share links slip past a privacy review because PII tools look for names and numbers, and a long URL with a random string reads as noise. Quoted replies repeat the same link many times, email footers carry tracking and unsubscribe tokens, and exported HTML keeps links that a plain-text view hides behind button labels.
Archives also outlive their context. A share link a project manager posted years ago may still open a folder of drawings or a customer's signed contract today, long after the person who created it left the company. Nobody remembers it exists, which is exactly why it is still open.
The find-and-neutralize procedure#
The find-and-neutralize procedure treats every URL as a finding until it is classified. Run it on the prepared export, not on live systems, and keep the output table as part of your preparation record.
Design placeholders for the reader, not only for safety. A buyer studying support work learns something when an agent sent a shared document, a reset link or an invoice portal link at a given step. A placeholder that keeps that role preserves the workflow while removing the door itself.
- Extract every URL from message bodies, HTML, attachment metadata and quoted text into a table with record ID and location.
- Classify by domain and pattern: file-sharing services, identity providers, storage endpoints, meeting platforms, payment and portal domains, and your own application domains.
- Flag URLs whose query strings or paths carry access material, such as parameters named token, access_token, sig, signature, key, code, auth or pwd, a username and password written before an @ sign in the address, or long random path segments.
- Replace flagged links with a typed placeholder that keeps the role, such as SHARED_DOC_LINK or PASSWORD_RESET_LINK, and strip query strings from the remaining links.
- Send the list of live-looking links to each system owner to revoke, expire or switch to named-user sharing.
- Re-scan the export and record what was replaced and what was revoked.
Use secret scanners, but add link rules#
Secret scanners help with the credentials that travel alongside links. Gitleaks, an MIT-licensed scanner, looks for passwords, API keys and tokens in repositories, loose files and piped input; its maintainer now describes it as feature complete, with only security fixes to come. TruffleHog, released under AGPL-3.0, reports that it recognizes more than 800 kinds of secrets and reaches chat, wiki and log sources as well as Git.
Neither kind of tool assumes that a document share link is a credential. Add custom patterns for the share domains and parameters your company actually uses, and treat any match as a finding.
Be careful with verification. TruffleHog can log in to confirm whether a secret is live, which means it sends real authentication requests. The same caution applies to links: opening a reset link may consume it, and opening a shared file is an access event in someone else's logs. Ask the system owner to check status from the admin side instead.
Neutralize in the export, revoke at the source#
Neutralizing a link in the export protects only that copy. The same link sits in mailboxes, backups and the original recipient's inbox, so revocation at the source is what actually closes the door.
Coordinate with whoever owns each system, and expect some links to belong to customers or partners. Those you cannot revoke; you can only remove them and notify.
| Action | What it protects | What it leaves open |
|---|---|---|
| Delete the URL | The export | The live link elsewhere; context is lost |
| Replace with a typed placeholder | The export, with meaning kept | The live link elsewhere |
| Revoke or expire at the source | Every copy, including old mailboxes | Nothing, once confirmed |
| Switch shares to named users | Future access | Anyone who already downloaded the files |
Illustrative: an engineering firm's RFI archive#
Illustrative: a fictional civil engineering firm prepared several years of RFI and submittal threads from project mailboxes and its project management system. Its IT lead extracted every URL before any review sample was drawn.
The table surfaced anyone-with-the-link folders holding drawing sets, presigned links in error reports from a field app, meeting links with passcodes for recurring coordination calls, and a chat webhook pasted into a ticket. Each was replaced with a typed placeholder. Project leads switched old folders to named-user access, IT rotated the webhook, and links to clients' own portals were reported to the clients rather than tested. The preparation record listed every finding with its final status.
Link findings and release authorization at SourceX#
During SourceX preparation, a link that opens a file, an account or a meeting is a finding with the same weight as a name or a password. The initial assessment shares only metadata, so no records carrying live links leave the company before this pass is done.
Findings, placeholder types and the revocation list are recorded in the privacy record of the SourceX Evidence Packet, and the supplier confirms revocation at the source before giving release authorization for Delivery.
Frequently asked questions
Are tracking and unsubscribe links a problem?
Usually a smaller one, but they can carry tokens that identify the recipient or act on a subscription without a login. Strip query strings from marketing and tracking links in the export, or replace them with a typed placeholder, rather than judging them one by one.
Should we keep normal links to our own public website?
Yes. Links to public help articles, product pages and documentation are useful context and grant no access. Keep them, or normalize them to the path without tracking parameters, so the buyer can see which article an agent sent.
What if a shared link points to a customer's system?
You cannot revoke it, so remove it from the export and tell the customer if the link appears to work from the address alone. Do not open it to check. Note the finding and the notification in your preparation record.
Do expired links still need removal?
Yes. Expiry is hard to confirm without testing, some links that look expired can be reissued, and paths can reveal account IDs or folder names. Replace them with typed placeholders in the same pass as live ones.
Who should own the revocation list?
The IT or security lead, with each system owner responsible for their own links. Track every finding to a status, such as revoked, expired, converted to named users or customer notified, before the dataset is approved for release.
Do links inside attachments and exported PDFs count?
Yes. Spreadsheets, PDFs and documents attached to tickets or emails often carry their own embedded links, including shares to other folders. If attachments are in scope, extract their links in the same pass, or exclude attachments until they can be scanned.
Sources
- Gitleaks is an MIT-licensed tool for detecting secrets such as passwords, API keys and tokens in git repositories, files and stdin. Source
- On May 21, 2026, the gitleaks README was updated to state that Gitleaks is feature complete and that future releases will be security patches only. Source
- TruffleHog, an AGPL-3.0 open-source secret scanner, says it classifies over 800 secret types, can log in to confirm whether a secret is live, and scans sources including Git, chats, wikis, logs, object stores and filesystems. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.