· via dev.to (home feed)
Bot harvested six API keys in six hours using Gmail dot-alias signups
A dev.to post describes how a bot used dotted Gmail aliases to farm six API keys from an unguarded signup endpoint, with verification mail landing on six real strangers.

Six signups overnight
A developer has described on dev.to how a bot pulled six API keys from their service in six hours by exploiting documented Gmail behaviour: Gmail treats dots in the local part of an address as meaningless, so [email protected] and [email protected] reach the same inbox. The behaviour is intentional, a design choice dating back to Gmail's early days, when addresses were often transcribed by hand.
The overnight signups used dotted variants such as [email protected]. Because the service's uniqueness check only lowercased the address before matching, each dotted string counted as a fresh account, and each fresh account was issued its own key.
Stripping the dots produced a second surprise. The addresses did not collapse into one attacker-controlled mailbox; they resolved to six different, plausible personal names. According to the author, the mutation looked like standard evasion behaviour baked into whatever automated tool ran the list, not a tactic aimed at this particular service. The consequence was that verification emails landed on six strangers who had never heard of the product — and, as the author notes, a few spam reports against a young sending domain can silently wreck deliverability at exactly the moment real users start arriving.
The guarded door sat next to the open one
The timing stung. One day earlier the team had opened a package-security lookup to keyless callers, with deliberately tuned limits: twenty requests per hour per address, five packages per request, and overage information returned in the response rather than left to documentation.
An API key bypasses all of that, and there were two ways to obtain one. The request-key endpoint mails the key and has enforced a per-address daily budget of five since it was written; a code comment states the budget exists to cap key-farming. The signup endpoint, meanwhile, took an email and password with no throttle at all — and because email verification was disabled by default in the deployment, it returned a working key directly in the HTTP response, no inbox required.
The remedy was about four lines of code: reuse the existing throttle function at signup and return a 429 once the budget is exhausted. The author's diagnosis is that endpoints which look dangerous get written carefully, while boring ones such as signup forms go unexamined even when they hand out the credential that neutralises every other limit.
The obvious fix is the wrong fix
The tempting response to Gmail aliasing is to normalise every address — strip dots, strip anything after a plus sign — before comparing. The post argues against doing that globally. Dots are insignificant only at Gmail; at Outlook, [email protected] and [email protected] are two separate mailboxes, potentially belonging to two different people at the same company. Fold dots everywhere and you will eventually tell a real user their account already exists, and that user will simply leave rather than report it. Plus-tags are safer but still not universal, since a plus sign is a legal character in a local part and only some providers route on it.
Canonicalisation therefore has to be per-provider: maintain a set of domains known to route plus-tags and a much smaller set — Gmail's domains, including googlemail.com — known to ignore dots. Two implementation details matter more than the function itself. First, persist the canonical form in its own column under a unique index and keep the original address exactly as typed: mail must be delivered to what the user wrote, and the canonical value should only ever answer whether two addresses are the same mailbox. Second, treat a failed unique-index migration as useful signal — it means two existing accounts already share an inbox, which is better discovered loudly than quietly absorbed by an insert-time check.
Why it matters
The author's core lesson is that throttling gets designed only where attention happens to be focused. A full day of care went into the keyless tier, while the adjacent path issuing keys that sidestep those numbers went unmetered because it was merely a signup form. The audit they recommend is simple: if a free tier contains a carefully chosen number, examine every route that hands out the credential which ignores it.
The incident is also a reminder that email is weaker identity than it appears. Gmail's dot handling is documented and permanent, dot-mutation is a routine tool in automated signup abuse, and verification defaults shape both exposure to abuse and the sender reputation of a young domain. The author closed with an apology to the six people whose addresses were used: the accounts were deleted and nothing was done with the mail.
- #api-security
- #rate-limiting
- #gmail
- #authentication