On January 19, 2023, T-Mobile disclosed that an attacker had been accessing personal data of approximately 37 million current customers through one of its APIs since late November 2022. The stolen data included names, billing addresses, email addresses, phone numbers, dates of birth, account numbers, and information about customers' service plans. T-Mobile stated that no passwords, payment card information, or Social Security numbers were compromised.
This was T-Mobile's ninth significant data breach since 2018. At some point, a pattern of breaches stops being bad luck and starts being a systemic security failure. The January 2023 breach was particularly notable because the attack vector, an unsecured API, is one of the most well-understood and preventable categories of vulnerability.
The Attack
T-Mobile's disclosure indicated that the attacker exploited a single API to access customer account data. The API was apparently accessible without proper authentication or with easily bypassed authentication controls. The attacker began data exfiltration around November 25, 2022, and continued until T-Mobile detected the activity on January 5, 2023, a period of approximately 41 days.
During those 41 days, the attacker queried the API to extract data for 37 million accounts. The rate of exfiltration, roughly 900,000 records per day, suggests either that the API had no rate limiting or that the rate limits were insufficiently restrictive.
T-Mobile stated they identified the attack through their security monitoring and shut down the exploited API within 24 hours of detection. However, the 41-day window between initial exploitation and detection raised serious questions about the effectiveness of their monitoring.
The API Security Gap
APIs have become the primary attack surface for modern applications, and the security industry has been raising alarms about API security for years. OWASP published their first API Security Top 10 in 2019. The T-Mobile breach hit multiple items on that list.
Broken Object Level Authorization (BOLA). The API apparently allowed the attacker to access any customer's data without proper authorization checks. A properly implemented API would verify that the authenticated caller has permission to access the specific resource they're requesting. BOLA vulnerabilities occur when the API checks that a user is authenticated but doesn't check that they're authorized to access the specific data they're requesting.
Lack of rate limiting. Extracting 37 million records over 41 days requires sustained, high-volume API queries. Rate limiting, both per-user and per-endpoint, would have either prevented the exfiltration or triggered alerts much sooner.
Insufficient monitoring. Forty-one days of anomalous API activity went undetected. Monitoring for unusual query patterns, volume spikes, and data access anomalies should have caught this activity within hours.
Excessive data exposure. The API returned more data than necessary for its intended purpose. API responses should include only the minimum data needed, following the principle of least privilege applied to data exposure.
T-Mobile's Breach History
The pattern of breaches at T-Mobile is striking:
- 2018: 2 million customer records accessed through an API
- 2019: Prepaid customer data exposed
- 2020: Employee email accounts compromised, customer data accessed
- 2020: Customer proprietary network information (CPNI) exposed
- 2021: 54 million customer records stolen including SSNs
- 2022: LAPSUS$ breached T-Mobile using stolen credentials
- 2022: Internal tools compromised through SIM swapping
- 2023: 37 million records via API exploitation
- 2023: A second breach affecting approximately 836 customers with highly sensitive data
Each breach followed a different attack vector, but the frequency suggests fundamental deficiencies in T-Mobile's security program. Individual vulnerabilities can be fixed, but a pattern of breaches across multiple attack surfaces points to organizational and cultural issues.
Why API Security Is Hard
T-Mobile's repeated API-related breaches reflect a broader industry challenge. APIs are difficult to secure for several structural reasons.
Surface area growth. Modern applications expose hundreds or thousands of API endpoints. Each endpoint is a potential vulnerability. The attack surface grows faster than security teams can audit.
Shadow APIs. Organizations often have APIs running that no one on the security team knows about: legacy endpoints, test APIs left in production, or undocumented internal APIs. You can't secure what you don't know exists.
Authentication vs. authorization. Many API security implementations focus on authentication (is this a valid user?) while neglecting authorization (is this user allowed to access this specific resource?). The distinction is critical but frequently overlooked.
Developer-centric design. APIs are designed by developers for ease of use, not security. Returning all available data in a response is convenient for development but creates unnecessary exposure in production.
Testing gaps. Traditional security testing tools are designed for web applications, not APIs. API security testing requires specialized tools and methodologies that many organizations haven't adopted.
Regulatory and Financial Impact
T-Mobile's repeated breaches have had significant financial consequences. They agreed to a $350 million settlement related to the 2021 breach and committed to spending $150 million on cybersecurity improvements. The FCC has also imposed requirements on T-Mobile's security practices.
For the 2023 breach, additional regulatory scrutiny was inevitable. The breach occurred during the period when T-Mobile was supposed to be implementing the security improvements mandated by the 2021 settlement. That the improvements failed to prevent another large-scale data breach underscored the challenges of remediating systemic security issues through compliance-driven mandates.
Lessons for API Security
Implement authorization at the object level. Every API endpoint should verify that the authenticated caller is authorized to access the specific resource they're requesting. Use the principle of least privilege.
Rate limit aggressively. Apply rate limits per user, per endpoint, and per time window. Set limits based on expected usage patterns, not theoretical maximums. Alert when limits are approached.
Monitor for anomalous access. Build behavioral baselines for API usage. A single user or credential accessing millions of records should trigger immediate alerts.
Minimize data exposure. Return only the data needed for each API's purpose. Don't include sensitive fields in endpoints that don't require them.
Inventory your APIs. You can't protect APIs you don't know about. Maintain a complete API inventory, including legacy and internal endpoints.
How Safeguard.sh Helps
Safeguard.sh helps development teams build security into their software from the start, reducing the risk of deploying vulnerable APIs to production. Our policy gates can enforce security standards including authentication requirements, input validation, and data exposure limits before code ships. Continuous vulnerability scanning catches known weakness patterns in your application dependencies that could lead to API-level compromises. When breaches like T-Mobile's happen because of preventable vulnerabilities, the answer is shifting security left into the development process rather than relying solely on runtime detection.