How a Missing Rate Limit in WhatsApp’s API Exposed Billions: Lessons in API Security
A single missing security control can unravel the privacy of billions. When researchers from the University of Vienna and SBA Research discovered that WhatsApp’s contact-discovery API lacked effective rate limiting, they didn’t just find a bug—they exposed a systemic flaw that allowed them to enumerate 3.5 billion active accounts, collecting profile photos, device details, and more, all at industrial scale. This wasn’t a theoretical risk: using just five authenticated sessions, the team queried over 100 million phone numbers per hour, ultimately assembling what could have been the largest dataset of its kind (BleepingComputer).
The WhatsApp incident is a stark reminder that even the world’s largest messaging platforms can stumble on basic API security. The absence of robust rate limiting—an essential defense against automated abuse—left the door wide open for systematic scraping. The resulting exposure dwarfed previous breaches, with global reach and long-term consequences for user privacy and trust. As we unpack the technical, organizational, and regulatory lessons from this case, it’s clear that the stakes for API security have never been higher.
How Rate Limiting (or the Lack Thereof) Became WhatsApp’s Achilles’ Heel
The Role of Rate Limiting in API Security
Rate limiting is a foundational security control for public-facing APIs, serving as a throttle to restrict the number of requests a client can make within a specific timeframe. Its primary purpose is to prevent abuse, such as brute-force attacks, enumeration, and large-scale data scraping. When properly implemented, rate limiting can detect and block anomalous traffic patterns, such as a single user or IP address making thousands of requests per minute. In the context of messaging platforms like WhatsApp, which handle billions of users globally, robust rate limiting is essential to safeguard sensitive user information from automated exploitation (BleepingComputer).
The absence of effective rate limiting exposes APIs to systematic enumeration attacks, where attackers can cycle through vast numbers of potential identifiers (such as phone numbers) to discover valid accounts and associated metadata. This vulnerability is particularly acute for services that use predictable identifiers, such as sequential phone numbers, as was the case with WhatsApp’s contact-discovery API.
WhatsApp’s Contact-Discovery API: A Case Study in Rate Limiting Failure
WhatsApp’s contact-discovery feature, which allows users to find which of their contacts are also using the platform, relies on an API endpoint known as GetDeviceList. This endpoint accepts phone numbers as input and returns information about whether the number is associated with a WhatsApp account, as well as device details. The researchers from the University of Vienna and SBA Research demonstrated that this endpoint lacked sufficient rate limiting, allowing them to automate requests at an unprecedented scale (BleepingComputer).
Using just five authenticated sessions from a single university server, the researchers were able to check over 100 million phone numbers per hour. Over the course of their study, they generated a global list of 63 billion possible mobile numbers and queried each one against the API. The lack of any meaningful throttling or blocking mechanisms meant that WhatsApp’s servers never intervened, even as the researchers’ activity far exceeded normal user behavior. As a result, they were able to enumerate 3.5 billion active WhatsApp accounts, collecting associated data such as profile pictures, “about” texts, and device information.
The Scale and Impact of Data Exposure Enabled by Absent Rate Limiting
The consequences of this rate limiting failure were far-reaching. By exploiting the API’s openness, the researchers amassed a dataset containing not only phone numbers but also timestamps, public profile information, profile photos, and public keys used for end-to-end encryption. In one test focused on US phone numbers, they were able to download 77 million profile photos without any hindrance, many of which contained identifiable faces and personal details (BleepingComputer).
The scope of the exposure was global, with the researchers identifying:
- 749 million active accounts in India
- 235 million in Indonesia
- 206 million in Brazil
- 138 million in the United States
- 133 million in Russia
- 128 million in Mexico
Notably, millions of accounts were found in countries where WhatsApp was officially banned, such as China, Iran, North Korea, and Myanmar, highlighting the platform’s reach and the comprehensive nature of the data collection. In Iran, for example, usage continued to grow even as the ban was lifted in December 2024.
The researchers’ analysis indicated that, had this dataset been released publicly or fallen into malicious hands, it would have constituted the largest data leak in history, surpassing previous incidents in both scale and sensitivity.
Comparative Analysis: Rate Limiting Failures Across Platforms
WhatsApp’s experience is not unique; the lack of effective rate limiting has been a recurring theme in several high-profile data breaches involving major online platforms. For instance, in 2021, a vulnerability in Facebook’s “Add Friend” feature allowed attackers to upload contact lists and check which contacts were on the platform. The absence of proper request throttling enabled the creation of a dataset containing 533 million users’ phone numbers, Facebook IDs, names, and genders (BleepingComputer).
Similarly, Twitter suffered a breach when attackers exploited an API vulnerability to match phone numbers and email addresses to 54 million accounts. Dell also disclosed that 49 million customer records were scraped after attackers abused an unprotected API endpoint. In each case, the common denominator was an API that allowed unlimited or poorly restricted lookups, making it trivial for automated scripts to enumerate vast numbers of records.
Meta, the parent company of WhatsApp and Facebook, confirmed that the WhatsApp data exposure resulted from automated scraping of an inadequately protected API. The Irish Data Protection Commission (DPC) subsequently fined Meta €265 million over the Facebook leak, underscoring the regulatory and reputational risks associated with such failures.
Technical and Organizational Oversights Leading to the Rate Limiting Gap
The WhatsApp incident highlights several technical and organizational oversights that contributed to the rate limiting gap:
Inadequate Threat Modeling
Effective threat modeling requires anticipating not only legitimate user behaviors but also potential abuse scenarios. In the case of WhatsApp, the contact-discovery API was designed for convenience, allowing users to quickly find friends and contacts. However, the design failed to account for the risk of automated enumeration at scale. The assumption that authenticated sessions would be sufficient to deter abuse proved incorrect, as the researchers demonstrated that even a handful of sessions could overwhelm the system.
Lack of Real-Time Monitoring and Anomaly Detection
Despite the extraordinary volume of requests originating from a single server, WhatsApp’s infrastructure failed to flag or block the activity. This suggests a lack of real-time monitoring and anomaly detection mechanisms capable of identifying and responding to suspicious patterns, such as an account or IP address making millions of requests in a short period.
Overreliance on Authentication Without Usage Controls
While WhatsApp required authentication for API access, this measure alone was insufficient. Without accompanying usage controls—such as per-user, per-IP, or per-session rate limits—authenticated sessions could still be abused. The researchers’ ability to maintain uninterrupted access throughout their study underscores the need for layered defenses that combine authentication with granular usage restrictions.
Delayed Remediation and Response
The researchers reported the issue to WhatsApp, and only then did the company implement rate-limiting protections to prevent similar abuse. The absence of proactive security reviews and regular API audits allowed the vulnerability to persist until it was externally disclosed. This reactive approach increases the window of exposure and the potential for exploitation by malicious actors.
The Long-Term Ramifications of Rate Limiting Failures
The fallout from inadequate rate limiting extends beyond immediate data exposure. Large-scale enumeration attacks can have lasting consequences for user privacy and platform trust:
- Persistent Utility of Leaked Data: Phone numbers and associated metadata remain valuable for years, enabling targeted phishing, social engineering, and account takeover attempts long after the initial breach. The researchers found that 58% of the phone numbers leaked in the 2021 Facebook scrape were still active on WhatsApp in 2025, illustrating the enduring risk (BleepingComputer).
- Cross-Platform Correlation: Attackers can combine datasets from multiple breaches to build more comprehensive profiles of individuals, increasing the effectiveness of malicious campaigns.
- Regulatory and Legal Consequences: Data protection authorities are increasingly imposing substantial fines for preventable data exposures, as seen with Meta’s €265 million penalty. Organizations face not only financial costs but also reputational damage and loss of user trust.
- Incentivizing Further Attacks: Publicized failures in API security can attract additional attackers seeking to exploit similar weaknesses, creating a cycle of escalating threats.
Lessons Learned and the Path Forward
The WhatsApp incident underscores the critical importance of implementing robust rate limiting as part of a comprehensive API security strategy. Key takeaways include:
- Proactive Security by Design: APIs should be designed with abuse prevention in mind, incorporating rate limits, anomaly detection, and layered authentication from the outset.
- Continuous Monitoring: Real-time analytics and automated alerts are essential for detecting and responding to unusual traffic patterns before they result in large-scale data exposure.
- Regular Security Audits: Periodic reviews of API endpoints and usage patterns can identify vulnerabilities before they are exploited.
- User Education and Transparency: Informing users about potential risks and the steps taken to mitigate them can help rebuild trust after an incident.
The WhatsApp case serves as a cautionary tale for all organizations managing large-scale APIs: the absence of effective rate limiting is not merely a technical oversight but a fundamental security flaw with far-reaching implications. (BleepingComputer)
Final Thoughts
WhatsApp’s API flaw is more than a cautionary tale—it’s a wake-up call for every organization managing large-scale digital platforms. The researchers’ ability to scrape billions of accounts with minimal resources underscores how a single overlooked safeguard can have global repercussions. This breach didn’t just expose phone numbers; it revealed how interconnected our digital identities have become, and how attackers can exploit even minor oversights to build detailed profiles for phishing, social engineering, or worse (BleepingComputer).
The lesson? API security isn’t just about authentication or encryption—it’s about anticipating abuse, monitoring for anomalies, and layering defenses like rate limiting from the start. As AI-driven attacks and IoT integrations multiply, the need for proactive, adaptive security controls will only grow. Organizations that treat API security as an afterthought risk not just regulatory fines, but the erosion of user trust and the integrity of their platforms.
References
- WhatsApp API flaw let researchers scrape 3.5 billion accounts. (2024). BleepingComputer. https://www.bleepingcomputer.com/news/security/whatsapp-api-flaw-let-researchers-scrape-35-billion-accounts/