Invite and Share Token Security: Guessable Links That Own Accounts

Invite and Share Token Security: Guessable Links That Own Accounts

Collaboration products live on links: invite teammates, share a doc, accept a calendar guest. Those URLs carry secrets. When the secret is short, reusable, or logged somewhere public, outsiders walk in as members.

Token bugs sit between auth and IDOR. Triagers understand them quickly if you show entropy, leakage, and what the token grants.

Token inventory

Map every “email me a link” or “copy link” flow:

• Org/workspace invites
• Document share links (/s/{token}, /share/{uuid})
• Magic login and “view as recipient” links
• OAuth device codes and pairing PINs
• Calendar and ticket guest access

Note lifespan, single-use vs multi-use, and whether acceptance binds to an email.

Failure modes that pay

Weak entropy. Sequential IDs, 6-digit codes, truncated UUIDs, or HMAC of guessable fields. Measure the search space; a few million attempts may be in-scope for labs but not for live spraying — prove weakness with math and a local oracle when rules forbid brute force.

Leakage. Tokens in Referer headers to third parties, JS analytics, server access logs mirrored to support tools, or NEXT_PUBLIC config. Password-reset style host-header issues also appear on invite emails — see PortSwigger’s password reset poisoning patterns applied to invite links.

Reuse and downgrade. An invite meant for alice@ accepted by any logged-in user. A read-only share token that also hits write APIs. An expired token still valid on an alternate subdomain.

Scope confusion. Token minted for project A grants project B because the redeem endpoint ignores resource binding.

Hunting steps

1. Issue invites/shares to accounts you control; capture tokens from email or UI.
2. Compare token formats across many samples — length, charset, predictability.
3. Redeem from a second browser with a different account; try without login.
4. Replay redeemed tokens; try partial tokens and encoding variants.
5. Check whether changing the email parameter on accept overrides the invite target.

For share links, open them while authenticated as an unrelated user and watch whether the app auto-joins you to a private workspace.

Safe demonstration

Prefer analytical entropy arguments and one successful cross-account redeem on your own tenants. Do not harvest other customers’ invites from leaked logs unless the program’s policy and your authorization clearly cover that.

Check secondary channels too: invite tokens inside calendar ICS attachments, QR codes on printed onboarding kits, and “copy invite” buttons that push the raw secret into clipboard managers or crash-reporting SDKs.

Fix recommendations worth pasting

• Use 128+ bits of secure randomness; store only hashes server-side
• Bind tokens to action, resource, recipient, and expiry
• Single-use for privileged invites; rotate on email resend
• Strip tokens from Referer (Referrer-Policy) and avoid putting them in query strings when body POST works
• Invalidate on role change or workspace deletion

Cross-link CWE-330 (insufficient randomness) and CWE-640 (weak password recovery — same link-handling class).

A share URL is a credential. Treat it like one in every report you file. When entropy looks borderline, ask for rate limits and monitoring on redeem endpoints as a temporary control while tokens are lengthened.