Trust by Default: The Five API Mistakes Driving Every Major Breach Right Now

Most API breaches don't announce themselves with sophistication. They arrive as boring mistakes, repeated so often across so many companies that they've stopped being surprising. Not zero-days. Not nation-state tradecraft. Just an API that trusted the wrong thing, because almost every API is built to trust by default — and trust is still the weakest security model in software. I've spent the better part of the last year and a half reading breach notification filings, the dry PDFs companies submit to state attorneys general after something has gone wrong. Most of them are written to say as little as possible. But once you've read enough of them, a pattern jumps out: across telecoms, healthcare administrators, automakers, and AI hiring platforms, the same handful of root causes keep showing up under different company names. Take June 2025. Researchers Ian Carroll and Sam Curry were testing McHire, the AI-driven recruitment platform several McDonald's franchises use to screen job applicants, built by a vendor called Paradox.ai. They weren't hunting for anything dramatic — they'd tried to break the chatbot with prompt injection and failed. Then they spotted a login link meant for Paradox staff, typed "123456" as both username and password, and were in. No multi-factor authentication stood in the way, CSO Online reported. That single test account ended up exposing roughly 64 million applicant records — names, emails, phone numbers, chat transcripts, personality-test results. Here's how: the admin account led to an internal API that fetched applicant data using a plain sequential ID. Decrement the number, get someone else's file. Two failures, stacked on top of each other, did all the damage: an authentication check that shouldn't have survived a five-minute review, and an authorization check that never existed at all. That's the thesis in miniature. Nobody had to invent anything to find either flaw. Both have had names, rankings, and documented fixes in the OWASP API Security Top 10 for years. The mistake isn't technical ignorance. It's that API development is optimized for shipping speed, and authorization correctness loses that race almost every time. Identity failures: BOLA and broken authentication Broken Object Level Authorization — BOLA, API1 on OWASP's list — has held the number one spot since the Top 10's first edition in 2019. The mechanism: an API checks that you're logged in, but never checks whether the record you're requesting actually belongs to you. Navia Benefit Solutions found out what that costs at scale. The Renton, Washington benefits administrator manages flexible spending accounts and COBRA coverage for more than 10,000 employers. Between December 22, 2025 and January 15, 2026, an unauthorized party exploited a BOLA flaw in Navia's API to pull Social Security numbers, dates of birth, and health plan records belonging to 2.7 million people — teachers, state workers, school administrators — according to the breach notice filed with the Maine Attorney General and covered by HIPAA Journal. Navia didn't detect the activity until January 23, and individual notification letters didn't go out until March 18 — nearly three months after the intrusion began. Volkswagen's My Volkswagen app had a near-identical authorization gap: substitute a different vehicle identification number into an API request and get back a stranger's address, insurance details, and in some cases real-time GPS location, per Equixly's research. But Volkswagen's flaw started one layer earlier, with API2 — Broken Authentication. The one-time password verifying vehicle-ownership transfers had no rate limiting and no lockout. A four-digit code has ten thousand combinations; a basic multithreaded script burned through all of them in seconds, because the API conveniently confirmed which guess was right. Authentication failures scale further when they hit infrastructure instead of individual accounts. In August 2025, attackers tracked as UNC6395 stole OAuth tokens from Salesloft's Drift chatbot integration — after first compromising Salesloft's GitHub environment months earlier — and used those tokens to pull CRM data from Salesforce instances belonging to more than 700 organizations , including Cloudflare, Zscaler, and Palo Alto Networks, according to SecurityWeek. Three companies whose entire business is stopping exactly this. Cloudflare alone had to rotate 104 of its own exposed internal tokens. The throughline: authentication isn't just "did this user log in correctly." It's how long a stolen token stays useful once it's out of your control, and whether your rate limits would even notice ten thousand rapid guesses. Data exposure failures: sending back more than you meant to OWASP folded Excessive Data Exposure and Mass Assignment into a single 2023 category — API3, Broken Object Property Level Authorization — because the cause is identical in both directions: an API that filters nothing at the field level, on the way out or the way in. Ethical hacker Eaton Zveare found this in an undocumented API tied to Intel's India partner portal. It was meant to return a basic user profile; manipulated parameters triggered a far more verbose response — internal metadata, role permissions, session tokens for other connected systems. The API shipped complete backend objects to the client and relied on the frontend to politely hide the sensitive parts, a shortcut that collapses the moment anyone talks to the API directly instead of through the app. Zveare walked away with a roughly 1GB file covering more than 270,000 Intel employees and suppliers , plus hardcoded credentials for several internal platforms, per Equixly's incident roundup. Volkswagen's APIs made the identical mistake on a different system: full JSON objects returned instead of filtered fields, including plaintext credentials for backend services like Salesforce CRM and payment processors — values a client app was never supposed to see. The fix isn't complicated, just unglamorous: decide what each endpoint is allowed to return, enforce that allowlist server-side, and stop assuming the frontend will look away from fields it shouldn't have received. System trust failures: misconfiguration and SSRF API8, Security Misconfiguration, is the catch-all for what a five-minute review should catch and somehow doesn't — debug modes left on, internal endpoints reachable from outside, services that answer any request without asking who's knocking. One 2025 case found exactly that: a client-side script calling an unauthenticated backend endpoint that minted privileged Microsoft Graph tokens on demand, exposing directory data for more than 50,000 users at the affected organization. Nobody attacked that system. It just answered the door for anyone who showed up. Server-Side Request Forgery, API7, is misconfiguration's more dangerous cousin. The reference case is still Capital One in 2019 — an SSRF flaw in a misconfigured firewall let an attacker reach AWS's instance metadata service and walk off with temporary IAM credentials, exposing roughly 106 million records. That weakness, exposed cloud metadata endpoints, hasn't gone anywhere. F5 Labs caught a four-day campaign in March 2025 systematically scanning AWS EC2 instances for SSRF flaws, specifically targeting older IMDSv1 configurations to steal IAM credentials, CSO Online reported. Both failures share a root: the API assumes anything that reaches it, or anything it's told to fetch, is legitimate by virtue of arriving. Allowlisting outbound destinations and requiring session tokens for metadata access — AWS's IMDSv2 model — close most of this off, and most organizations still haven't flipped the switch. Visibility failures: the API you forgot you were running API9, Improper Inventory Management, is the least dramatic entry on the list, which is exactly why it persists. You can't secure an endpoint you've forgotten exists. Stripe learned this in 2025 without any fault in its current infrastructure. A skimming campaign found that a deprecated endpoint, /v1/sources , was still wired into backend payment validation. Attackers flooded it with stolen card numbers, using pass/fail responses to quietly confirm which cards were still active before reselling the good ones — a campaign that hit at least 49 online retailers , per Equixly. The endpoint sat outside Stripe's actively monitored inventory, so the unusual traffic pattern never tripped the alarms a catalogued endpoint would have. It echoes Optus's 2022 breach in Australia, where a forgotten, unauthenticated customer-facing API exposed 11.2 million records — still cited in training decks because the failure was so avoidable. The remedy is process more than technology: a living inventory of every API version including non-production ones, a retirement date assigned at launch rather than after someone notices an endpoint is still live, and treating "we forgot it existed" as its own category of incident. Why these mistakes never die None of this is a knowledge problem. Every flaw above is documented, ranked, and has a known fix. They keep recurring because of how API development actually gets built under deadline pressure: Speed beats correctness in almost every roadmap decision. Shipping the endpoint earns credit; checking whether every caller is authorized to hit it does not, until the breach notice forces the question. Teams over-trust their own frameworks. Authentication gets handled once, at the gateway, and everyone downstream assumes the hard part is done. It isn't — object-level and field-level checks have to happen inside the application logic itself, which is exactly the layer gateways don't see. And increasingly, the caller on the other end isn't human. A growing share of API traffic now comes from AI agents acting on someone's behalf, frequently running with broad standing permissions because nobody wanted to slow the agent down with granular checks. OWASP added API6, Unrestricted Access to Sensitive Business Flows, specifically because automation turns a slow manual workaround into an instant, repeatable exploit. Every mistake above gets worse, not better, when the thing making the request never gets tired and never second-guesses itself. The problem was never that APIs are insecure by nature. It's that they're trusted by default, and almost nothing in how they're built forces that trust to be earned on a per-request basis. Until that changes, the breach notices will keep reading the same way: a different company name, the same five-year-old mistake. Sources CSO Online — McDonald's AI hiring tool's password "123456" exposed data of 64M applicants Equixly — 2025 Top 5 API Incidents HIPAA Journal — Navia Benefit Solutions Discloses Data Breach Affecting 2.7 Million Individuals SecurityWeek — Security Firms Hit by Salesforce–Salesloft Drift Breach CSO Online — Hackers target SSRF flaws to steal AWS credentials OWASP API Security Top 10 (2023 edition): API1 — Broken Object Level Authorization API3 — Broken Object Property Level Authorization API7 — Server Side Request Forgery API8 — Security Misconfiguration API9 — Improper Inventory Management Full Top 10 overview \