Paste a link into a chat message and, a moment later, a preview appears: a title, an image, a short description pulled from the page. Nobody clicked anything. A server somewhere fetched that URL, read its metadata, and rendered a card, entirely automatically, the instant the link was posted.
That automatic fetch is a request your infrastructure did not choose to make, sent by a third party's server, to whatever address appeared in a message a user typed. It is a small, specific, and frequently overlooked case of the same class of problem as any other server-side fetch of a user-supplied URL, and it has two properties that make it particularly worth understanding: it happens without anyone clicking, and it happens on infrastructure you do not control.
Why this is not the same as clicking a link
A user who clicks a link makes a request from their own browser, with their own cookies, their own network position, their own consent implicit in the act of clicking. A link that gets unfurled is fetched by the chat platform's own server, from its own network position, with none of that context, the moment the link is posted, regardless of whether anyone ever reads the message or clicks anything.
This means a URL posted into a chat message is fetched at least once, automatically, by an infrastructure component you have no visibility into and no control over, and that fetch happens before any human decision has been made about whether the link should be visited at all.
Where this becomes your problem rather than the chat platform's
A URL containing a capability, a token, a signed link, a one-time code, posted into a chat message for a legitimate reason, sharing a document, forwarding a notification, pasting a support link, gets consumed by the unfurling fetch before the intended human recipient ever sees the message. A single-use link is used up by the preview generator. A time-limited token has its window consumed by an automated request that has nothing to do with the person the link was meant for.
An internal or otherwise non-public URL, pasted into a chat by mistake or out of habit, gets fetched by the unfurling service, which for some platforms runs from infrastructure that may be positioned differently than a typical external client, occasionally reaching addresses that a deliberately hostile external actor could not reach directly, depending on the platform's own network configuration and any server-side request forgery protections it does or does not have in place.
A URL you control, designed to detect when it has been visited, receives a hit from the unfurling fetch rather than, or in addition to, a hit from the intended human recipient, which can corrupt any analysis that assumes a fetch corresponds to a person actually viewing the link, including security tooling built around exactly that assumption for phishing detection or access logging.
The reverse direction: your own product doing the fetching
If your product implements link previews for content users paste, share, or receive, whether that is a chat feature, a document with embedded links, or any interface that shows a preview card for a URL, you are the one operating the fetching infrastructure this entire problem describes, and every consideration that applies to any other server-side fetch of a user-supplied URL applies here specifically, because a link preview feature is exactly that: a server fetching a URL chosen by a user, then rendering the result.
The specific things worth checking for a preview-generation feature: does it resolve and reject requests to internal address ranges and link-local addresses before fetching, does it follow redirects and re-check the destination after each hop rather than only the original URL, does it run from network infrastructure with no meaningful reachability into anything you would not want a public-facing fetch to reach, and does it cap response size and fetch time so that a slow or enormous response cannot be used to tie up the fetching infrastructure.
What to actually do, on both sides of this
Treat any single-use or time-limited link as consumed the moment it is generated, not the moment a human clicks it, if there is any possibility it will pass through a chat platform, an email client, or any other tool that might unfurl or preview it automatically. Design the flow so that the link itself grants nothing directly and instead leads to a step that requires the actual authenticated user to complete, rather than authenticating or authorising anything based on the link being fetched at all.
Never assume a fetch of a URL corresponds to a human having seen it, for any purpose, security monitoring, analytics, or access logging, because automated unfurling means a meaningful share of the first fetch against many URLs comes from a chat or email platform's preview infrastructure rather than from the person the link was actually sent to.
If you build a preview or unfurling feature yourself, apply the same server-side request forgery discipline you would apply to any other feature that fetches a user-supplied URL, because it is precisely that feature, regardless of how minor or cosmetic the preview functionality feels compared to a more obviously consequential integration.
Be specifically cautious about pasting internal, unauthenticated, or time-sensitive links into any chat tool, as a matter of practice, not because the chat platform is poorly built, but because unfurling by design means the link gets fetched by something other than the intended recipient, and that fetch has already happened by the time anyone reads the message.
Check yours
If your product generates any tokens, links, or one-time codes that might reasonably end up pasted into a chat application, test specifically what happens when the link is posted into a chat tool that performs automatic preview generation, and observe whether the token or code is consumed by that automatic fetch before you, the actual intended recipient, ever click it yourself.
The concession
Link previews are a genuinely useful feature, adopted broadly because they make shared links substantially more informative and because building a chat or messaging product without them is a real usability regression that most products and their users would not accept. This is not an argument against the feature existing.
It is an argument for treating the fetch it performs with the same seriousness as any other automated request to a user-controlled destination, on whichever side of the interaction you sit: as the operator of a preview feature, applying real request validation, or as the operator of a service issuing links, designing those links to survive being fetched by something other than their intended recipient.
The implication
A link posted into a chat message is not seen once, by the person it was addressed to, at the moment they choose to look. It is fetched at least once, automatically, by infrastructure you do not control, at the moment it is posted, and any security property that depends on the fetch and the human viewing happening together, at the same time, by the same actor, does not hold.
If your product issues single-use links or time-limited tokens, ask specifically what happens to them when pasted into a modern chat tool. The answer, tested rather than assumed, is very likely that they get consumed before anyone was supposed to use them at all.
