Invite Links Are Bearer Tokens: Access Control and Phone-Number Exposure in Large WhatsApp Groups
A credential nobody rotates
A WhatsApp invite link behaves like a bearer token. Whoever holds it can join, and the Help Center confirms that anyone with the link can also forward it. There is no expiry by default, no scope and no binding to an identity. Once the token is published on a website, a social network or a forum, the group's access control list becomes public.
Joining has a side effect engineers should treat as a data disclosure: members can see each other's phone numbers. So a leaked link is not only an unwanted entry problem. It is an enumeration path for a list of personal identifiers.
Ivan Schroll's report argues that access control is the main privacy instrument available at group level. The admin cannot change the fact that members see numbers. The admin can decide who reaches that list.
What the measurements show
- Garimella and Tyson (2018) showed that public WhatsApp groups can be discovered through links scattered across the web and joined for data collection.
- Hoseini and colleagues (2020) collected 351,000 unique group URLs for WhatsApp, Telegram and Discord posted on Twitter in 38 days. In the WhatsApp groups they joined, the numbers of 54,984 users were visible to them as members.
- The same study found that 27% of WhatsApp group links stopped working within the 38 days, which suggests admins revoke or reset links over time, often after exposure.
- Gegenhuber and colleagues (2026) showed that WhatsApp numbers could be enumerated at large scale through contact discovery before the platform applied remediation, which is why rate limits matter.
Control plane
| Control |
Applied by |
Effect |
| Approve new members |
Admin |
Link join requests wait for approval |
| Restrict who adds members and shares the link |
Admin |
Narrows who can distribute the token |
| Reset invite link |
Admin |
The old link stops working and cannot be restored |
| Keep links off public pages |
Admin |
Reduces discoverability |
| Avoid @mentions in announcement groups |
Admin |
Avoids exposing numbers to the whole community |
| Who can add me to groups |
User |
Limits unsolicited additions |
| Usernames and username key |
Platform and user |
Contact without sharing a number, rolling out gradually |
| Rate limits on contact discovery |
Platform |
Reduces enumeration at scale |
Tooling layer and its limits
- Consistent screening. Approval with filters, daily limits and history. Filters only see the data available at entry and cannot verify intent.
- Burst protection. Daily approval caps and anti-flood rules slow mass entry, but a single targeted account still gets through.
- Membership hygiene. Removing inactive members, with prior notice, reduces passive observers.
- Time-boxed access. Fixed-period membership fits courses, events and paid communities.
- Audit. Approval and moderation history support accountability, and the records themselves contain personal data.
Engineering conclusion: treat the link like a secret
Apply the same hygiene you use for API keys.
- Do not publish it. WhatsApp's own community guidance says never to post invite links on public web pages.
- Gate redemption. Enable approval so possession of the link is not sufficient. When requests are frequent, rules can auto-approve WhatsApp group members that match filters, under a daily limit, with a record of every decision.
- Rotate on leak. Reset the link when it appears somewhere it should not. This explainer on the WhatsApp group invite link covers how links are created, shared and revoked.
- Restrict distribution rights. Only admins should add members or share the link in large groups.
- Minimise the directory. If members do not need to talk, an announcement format exposes less.
Welcome messages that state the rules inform new members, but they do not prevent link leakage on their own. The boundary is the approval step.
Source: Ivan Schroll (2026), Access Control and Member Privacy in Large WhatsApp Groups: Invite-Link Exposure, Phone-Number Disclosure and Unwanted Entry. DOI 10.17605/OSF.IO/WFDQ3
Author: Ivan Schroll (ORCID 0009-0007-0680-5570)