Why you should hack your own APIs

### Overview In this presentation, Dan Barona, co-founder of APIsec University, explains why application programming interfaces (APIs) have become the primary attack vector across modern software and why organizations must actively hack and test their own APIs. Citing historical data from Akamai (83% of internet traffic is API traffic) and Gartner (APIs as the most frequent attack vector), Barona emphasizes that attackers routinely bypass client-side user interfaces (UIs) to interact directly with backend endpoints, exposing logic flaws, over-permissioned access, and excessive data.

### Key Topics - **UI vs. API Security Decoupling**: Security controls enforced solely within front-end applications fail when attackers make direct API calls. - **Real-World Breach Case Studies**: Analysis of major security incidents at Coinbase, Peloton, Duolingo, Venmo, and Trello. - **OWASP API Security Top 10 Core Weaknesses**: Broken Object Level Authorization (BOLA), Broken Authentication, and Excessive Data Exposure represent the vast majority of API breaches. - **The Testing Gap**: Disparities between business logic development cycles and automated security testing, contrasted with traditional DAST, SAST, and manual penetration tests. - **API Governance and Discovery**: Managing shadow APIs, documentation drift, and version deprecation.

### Technical Details Barona breaks down several real-world incidents to highlight root vulnerabilities: - **Coinbase**: A security researcher altered four parameters in an API trading request payload (specifying a sell of Ethereum while changing the currency to Bitcoin). Due to a missing logic validation check at the application layer, the system credited $43,000 without verifying whether the user owned Bitcoin. Firewalls and anomaly detection failed to detect this because the request payload matched legitimate schema structures. - **Peloton**: An unauthenticated API endpoint initially allowed unauthorized access to user records. When Peloton added authentication, it failed to implement proper authorization checks (OWASP API #1 / BOLA), enabling any authenticated user to retrieve data for all 4 million accounts. - **Duolingo & Trello**: Exposed backend endpoints allowed account enumeration and scraping. Duolingo returned user profile details upon receiving an email address without authentication (OWASP API #2). In Trello's case, an attacker fed 500 million harvested email addresses into an invite endpoint, successfully correlating 15 million account profiles despite deployed WAFs and basic rate limiting, achieved via proxying, IP rotation, and request throttling. - **Venmo**: The platform relied on the UI to filter out sensitive personal transaction data. The underlying public API returned entire unredacted records, enabling scrapers to harvest 200 million transactions (OWASP API #3, Excessive Data Exposure).

An analysis of major high-profile incidents revealed that 90% mapped directly to OWASP API #1, #2, and #3. Furthermore, Barona cites a State of APIs report from RapidAPI showing that 96% of API testing focuses on positive ("happy path") testing, while only 4% focuses on negative security testing.

### Takeaways - **Never Treat the UI as a Security Boundary**: Backend business logic must independently enforce data filtering, authorization, and validation. - **Shift Security Testing Left**: Relying on periodic manual pentests (once or twice a year) against daily or weekly deployment cycles leaves a critical gap. Organizations should introduce automated security testing into CI/CD pipelines (such as running tools like APIsec University's free CLI scanner, apiscan, locally within GitHub pipelines). - **Implement Strict API Governance**: Organizations should document endpoints, deprecate legacy versions (e.g., /v1, /v2) systematically, and maintain multi-pronged discovery strategies across engineering teams, code repositories, and WAF traffic inspection.