Why Slack Link Previews Burn One-Time Secrets (And How to Prevent It)
TL;DR
Chat apps like Slack fetch pasted URLs to build link previews (unfurls). If your one-time secret tool deletes ciphertext on the first GET, that automated fetch can burn the secret before your recipient clicks. Fix it with an explicit Reveal step, deliver the full URL out-of-band, or post “credentials separately” in unfurling channels. VanishingVault uses Reveal hardening so typical unfurls do not consume the one view.
Related: is Slack encrypted? · send a password as a one-time link · how to share passwords securely · best one-time secret sharing tools.
What Happens When a One-Time Link Dies in Slack Before Anyone Clicks?
A support lead pastes a one-time secret link into #client-onboarding with the note “DB password for staging — open once.” Within seconds Slack renders a link preview card. Two minutes later the developer clicks the URL and sees not found. Nobody else on the team opened it.
What happened is not a bug in the secret tool — it is a predictable collision between burn-after-read and link unfurling. Slack's servers fetched the URL to build the preview. That HTTP GET looked like a retrieve to the backend. Ciphertext deleted. The human never got a chance.
We see this in handoffs every week: teams switch from pasting passwords in chat (good) to pasting one-time links (better) but still lose the secret to preview bots (bad). This page is the standalone incident-style explainer our guides reference — so support and security teams have something concrete to cite.
Why Do Slack and Other Chat Apps Fetch URLs You Paste?
Unfurl / link preview
Slack, Teams, Discord, and LinkedIn fetch URLs server-side to extract title, description, and Open Graph images for the inline card. That fetch uses Slack's infrastructure — not the recipient's browser.
Security scanners
Mail clients and secure email gateways fetch links for malware and phishing checks. Same problem: an automated GET before the human opens the message.
These fetches are normal product behavior. They become a incident when your secret-sharing backend treats any successful retrieve as the one view and deletes the blob. The preview bot does not know it just burned a credential — and neither does the sender until the recipient complains.
How Does Burn-After-Read Interact With Link Previews?
A typical zero-knowledge one-time link works like this:
- Browser encrypts the secret client-side and uploads ciphertext.
- Share URL = path ID + decryption key in the
#fragment. - Recipient opens URL; browser fetches ciphertext and decrypts locally.
- Server deletes ciphertext so the link cannot be reused.
The failure mode appears at step 3 when whoevertriggers the retrieve counts as the viewer. If the retrieve API is hit on the first GET — including Slack's unfurl bot — the secret is gone. Fragments stay client-side (good for zero-knowledge), but the burn decision is server-side (vulnerable to any GET that reaches the burn endpoint).
| Actor | What it does | Burn risk |
|---|---|---|
| Human recipient (clicks Reveal) | Intended one view; secret delivered | None — this is the design |
| Slack / Teams unfurl bot | GET for Open Graph / preview metadata | High if first GET burns |
| Email security scanner | HEAD/GET link in quarantine pipeline | High if first GET burns |
| Browser prefetch / extensions | Speculative fetch of hovered links | Medium — depends on tool design |
How Can You Prevent Unfurls From Burning One-Time Secrets?
Use a tool with an explicit Reveal step
VanishingVault loads a landing page on first request. Ciphertext is retrieved and deleted only when the human clicks Reveal. Typical unfurl bots fetch once for metadata and stop — they do not simulate button clicks.
Send the URL out-of-band
Post “sending credentials separately” in the channel, then deliver the full link by DM, SMS, signal, or phone. Channels that unfurl are fine for coordination; the bearer URL travels on a path preview bots do not see.
Never paste the password — only the link
Even a burned link is better than a live password sitting in searchable Slack history. See send a password as a one-time link for the full workflow.
Confirm receipt on a second channel
Call or message the recipient after they should have opened the link. Bearer URLs mean whoever opens first wins — confirmation catches wrong-party views and unfurl accidents early.
Do Teams, Discord, and Email Have the Same Problem?
Yes. Any platform that fetches URLs for previews or security scanning can consume a one-view secret if the backend burns on first GET:
| Platform | Preview behavior | Best for handoff | Honest limit |
|---|---|---|---|
| Slack | Server-side unfurl for link cards | Announce “credentials separately”; URL in DM | Workspace may still log the dead URL in channel history |
| Microsoft Teams | Link previews in channels and chat | Same as Slack — coordinate in channel, link out-of-band | Tenant policies vary; assume previews are on |
| Email (Outlook, Gmail) | Security scanners + rich preview in some clients | Email the link; confirm by phone for high risk | Inbox retains URL even after burn — metadata leak |
| SMS / Signal DM | Usually no server-side unfurl of arbitrary URLs | Delivering the bearer URL after channel heads-up | SMS is not E2EE; fine for link, not for password plaintext |
Slack's broader encryption model (not E2EE, searchable history) is covered in is Slack encrypted?.
Reveal Hardening vs Raw Burn-on-GET — Which Fits?
| Design | Best for | Honest limit | Unfurl safe? |
|---|---|---|---|
| Burn on first GET to retrieve API | Nothing in chat or email — too fragile | Any preview bot or scanner consumes the view | |
| Landing page + Reveal click (VanishingVault) | Slack-adjacent handoffs when you must paste a link | Bearer URL; confirm recipient out of band | |
| Out-of-band only (DM / SMS / call) | High-sensitivity credentials | Extra step for sender; worth it for staging/production secrets | |
| Password in Slack plaintext | Never | Searchable forever; admin export; no burn |
What Should Your Team Put in the Handoff Checklist?
Before you send
- • Create a one-time link — never paste the password
- • Know whether the target channel unfurls links
- • Plan out-of-band delivery for production credentials
- • Use a tool with Reveal hardening
After you send
- • Confirm recipient opened the link (call / separate chat)
- • If “not found” — assume unfurl burn; reissue out-of-band
- • Rotate credential if wrong party may have viewed
- • Document “credentials separately” norm for the team
For step-by-step creation and Bitwarden Send comparison, see send a password as a one-time link. For crypto and architecture detail, see AES-256-GCM in the browser for secret sharing.
When Should You Escalate Beyond a One-Time Link?
One-time links fix the durability problem (chat history) and, with Reveal hardening, the unfurl problem. They do not replace:
- Ongoing shared access — use a password manager vault for team credentials.
- High-volume automation — use Secrets Manager or scoped API tokens with rotation, not links in chat.
- Regulated data at rest in Slack — unfurl burns are a symptom; the root issue is using Slack as a secret store. See is Slack encrypted?
Frequently Asked Questions
Why does pasting a one-time secret link into Slack sometimes burn the secret before the recipient opens it?
Slack (and many chat apps) fetch URLs to build link previews — unfurls. That automated GET can hit the same retrieve endpoint a human click would. If the one-time secret tool deletes ciphertext on first retrieve, the preview bot consumes the one view. Your recipient then sees an expired or not-found page even though they never clicked.
Does Slack unfurl every URL I paste?
Slack attempts to unfurl most http(s) links posted in channels and DMs when link previews are enabled for the workspace. Admins can restrict unfurling for some domains, but you should assume any pasted URL may be fetched by Slack infrastructure before a human reads the message.
How do I prevent Slack from burning my one-time secret link?
Three practical patterns: (1) use a tool with an explicit Reveal step so the first GET loads a landing page, not the burn endpoint; (2) post “credentials coming separately” in the channel and send the full URL out-of-band (DM, SMS, phone); (3) disable or avoid unfurling channels when you must paste a raw link. Never paste the password itself — only the link.
Can Microsoft Teams or email link previews burn one-time secrets too?
Yes. Teams, Discord, LinkedIn, iMessage link previews, and many mail clients (Outlook, Gmail security scanners) fetch URLs for previews or malware checks. Any burn-after-read design that counts the first GET as a view is vulnerable. The mitigation is the same: explicit Reveal UI, out-of-band delivery, or channels that do not auto-fetch.
Is it safe to paste a one-time secret link into Slack at all?
Safer than pasting the password — after burn, chat history holds a dead URL, not a live credential. But unfurl risk remains. Prefer out-of-band delivery for high-sensitivity handoffs. See our guides on whether Slack is encrypted and how to send a password as a one-time link.
What is an explicit Reveal step and why does it help?
A Reveal step means the first HTTP request loads a static landing page that does not delete the secret. Only when the human clicks Reveal does the browser call the burn-after-read retrieve API. Automated unfurl bots typically fetch the landing page once and stop — they do not simulate a button click — so the ciphertext survives until your recipient acts.
How do I know if my one-time link was burned by a preview bot?
Symptoms: the recipient opens the link and sees “not found,” “already viewed,” or an empty page; you never got confirmation they saw the secret; Slack shows a preview card in the channel before anyone clicked. Fix: create a new link, deliver it out-of-band, and confirm receipt on a call or separate chat.
Should I disable Slack link previews workspace-wide?
Disabling unfurls reduces accidental burns but hurts everyday collaboration. Most teams instead adopt a handoff policy: announce in-channel, deliver credentials via one-time link in a DM or SMS, and use tools with Reveal hardening. Combine with MFA and retention policies — see is Slack encrypted for the broader Slack security model.
Does VanishingVault protect against Slack unfurl burns?
VanishingVault serves a landing page on first load; the secret is retrieved and ciphertext deleted only after the recipient clicks Reveal. That design prevents typical unfurl GETs from consuming the one view. You should still confirm the intended recipient out of band — the URL remains a bearer secret.
What should I do if the secret was burned before delivery?
Assume the preview bot or an unintended fetch consumed the view. Create a fresh one-time link, send it on a channel that does not unfurl (or out-of-band), confirm the recipient opened it, and rotate the underlying credential if there is any chance the wrong party got there first.
Share secrets without losing them to Slack unfurls
VanishingVault encrypts in your browser, uses Reveal hardening against preview bots, and destroys ciphertext after one view.
Create a one-time secret