The contemporary digital economy is increasingly reliant upon the seamless exchange of data between disparate systems, a requirement that has elevated Application Programming Interfaces (APIs) from simple backend tools to the foundational pillars of modern software architecture. As organizations undergo rapid digital transformation, the shift from monolithic application structures toward microservices and cloud-native environments has created a sprawling web of interconnectivity. This architectural evolution is evidenced by the fact that API traffic now constitutes approximately 57% of all dynamic internet traffic globally, reflecting a monumental transition in how data is consumed and processed.1 However, this explosive growth in API adoption—characterized by a 30% increase in API volume for many enterprises and growth exceeding 100% for a significant quarter of organizations—has outpaced the development of robust security frameworks.3 The resulting "governance gap" has exposed critical vulnerabilities, most notably in the realm of broken authorization and improper inventory management. Recent high-profile events, including the 2022 Optus data breach in Australia and the 2025 research into S&P 500 firms utilizing the AutoSwagger discovery tool, have highlighted the systemic nature of these risks. These incidents demonstrate that even the world’s largest and most technologically sophisticated corporations are susceptible to basic authorization failures that can be exploited with minimal technical skill.
The transition to microservices was initially championed as a means to enhance system resilience and security through isolation. In theory, by breaking a monolithic application into smaller, independent services, an organization could limit the blast radius of a potential compromise. However, the practical implementation of this architecture has led to what industry experts define as the "Microservices Security Paradox".4 Rather than creating isolated, secure enclaves, organizations have inadvertently created a massive internal attack surface. Audits of over forty B2B Software-as-a-Service (SaaS) platforms revealed that the average environment now supports approximately 73 internal APIs.4 The critical failure lies in the underlying assumption that the internal network is a trusted environment. This "castle-and-moat" mentality has resulted in a landscape where 31% of internal APIs lack any form of authentication, 68% fail to validate security tokens correctly, and 89% implement no rate limiting on internal endpoints.4 In such environments, the compromise of a single internal service can lead to lateral movement and widespread data exfiltration, as these disparate pieces of the broken monolith often trust each other blindly.4
This lack of internal oversight is compounded by the phenomenon of "Shadow APIs"—undocumented or uninventoried endpoints that exist outside the purview of the central security team. Market data indicates that machine learning discovery tools consistently identify approximately 30.7% more API endpoints than what organizations self-report, suggesting that nearly a third of an enterprise's API estate is effectively invisible and therefore unsecured.2 These shadow APIs are frequently the result of rapid development cycles where "automatic documentation" is seen as a convenience for developers but a liability for security.6 When APIs are designed to be self-documenting through tools like Swagger or OpenAPI, they often inadvertently expose their internal structure, parameter requirements, and data types to the public internet.7
Arguably the most significant modern example of the dangers inherent in unmanaged API exposure is the September 2022 data breach of Optus, Australia's second-largest telecommunications provider. The incident served as a wake-up call for the global cybersecurity community, illustrating how a single unauthenticated endpoint can lead to the compromise of a nation's sensitive data. The breach affected between 9.5 million and 10 million current and former customers, representing roughly 40% of the Australian population.9
The Optus breach was not the result of a sophisticated nation-state attack or a zero-day exploit. Instead, it was an exploitation of an unauthenticated API endpoint left exposed on a dormant subdomain.10 This endpoint was connected to a customer database but lacked any requirement for an API token, key, or user login.10 The vulnerability was a classic case of Broken Object Level Authorization (BOLA), also known as Insecure Direct Object Reference (IDOR). The attacker identified that the API endpoints were structured predictably, likely utilizing a format such as /users/{userId}. By simply incrementing the userId in a basic Python loop, the attacker could systematically query and receive sensitive customer records.10
The failure at Optus was two-fold: a failure of inventory management (the dormant subdomain) and a failure of authorization logic (the lack of per-object checks). The system verified neither the identity of the requester nor their right to access specific object instances.10 This simplicity is what makes BOLA the most dangerous vulnerability in the modern API landscape, as it allows attackers to bypass traditional security controls by abusing legitimate application workflows.11
The consequences for Optus extended far beyond immediate technical remediation. The breach triggered a national security crisis in Australia, requiring federal and state government agencies, including the Australian Cyber Security Centre (ACSC), to coordinate a massive identity replacement program.9 In Queensland alone, the Department of Transport and Main Roads was forced to replace over 178,000 driver's licenses.9 The incident also led to a $1.5 million ransom demand in Monero cryptocurrency on a dark web forum, though the attacker later claimed to have deleted the data and issued an "apology".10
The fallout included significant legal challenges, such as class action investigations by law firms like Slater & Gordon and Maurice Blackburn.17 Furthermore, the breach highlighted the risks of excessive data retention. Millions of the records exposed belonged to individuals who were no longer Optus customers, some dating back years, which increased the organization's attack surface unnecessarily.14 This led to a broader regulatory shift toward data minimization—the principle that if an organization does not need data, it should not hold it.9
To address the recurring theme of exposed and unauthenticated APIs, the security research firm Intruder developed and released AutoSwagger in 2025. AutoSwagger is an open-source command-line tool designed to automate the discovery, parsing, and testing of Swagger and OpenAPI documentation for authorization flaws.20 The tool's existence underscores a critical reality in modern cybersecurity: the same tools that help developers build applications faster can be weaponized by attackers to find vulnerabilities more efficiently.
AutoSwagger leverages the "self-documenting" nature of modern APIs to map an organization's attack surface. It functions through a series of systematic phases designed to identify endpoints that return sensitive data without proper authentication.
The research team at Intruder noted that the vulnerabilities AutoSwagger finds are so simple to exploit that they could be taught to a non-technical user in a single day.6 This simplicity is what makes them so pervasive. Developers often prioritize speed and ease of integration, leading them to deploy extensions or plugins that expose API documentation for easier consumption by internal teams or partners. However, if these documentation pages are internet-facing, they provide a "map" for attackers to find deeply nested and complex paths that would be impossible to discover through traditional brute-force.6 For example, a path like /1/dashboard/mpn/program/api/config/ is six layers deep; without the schema provided by Swagger, an attacker would never guess its existence.6
In 2025, Intruder conducted a research sweep of S&P 500 firms and major bug bounty targets using AutoSwagger, uncovering a range of critical authorization weaknesses in large-scale production environments.6 These findings demonstrate that even three years after the high-profile Optus breach, basic API security hygiene remains a major challenge for the world's most prominent companies.
One of the most striking findings involved the Microsoft Partner Network. Researchers identified an unauthenticated endpoint named /config that was publicly accessible.6 This single endpoint exposed an extensive list of production credentials and API keys for various Microsoft Partner Program data stores. Among the exposed secrets were valid credentials for a Redis database.6 Upon verification, these credentials allowed direct access to a database containing the personally identifiable information (PII) of Microsoft Partners, including their names, email addresses, and specific details regarding the training courses and certifications they had completed.6 This data is highly valuable for targeted phishing campaigns, as an attacker could pose as internal HR or training staff using legitimate, verified details to gain the trust of employees.6
Another critical vulnerability was discovered in an API running on Azure Functions for a well-known multinational soda corporation.6 The API supported an internal staff training application but was inadvertently exposed to the internet with broken authentication. The researchers discovered an endpoint that allowed the execution of arbitrary SQL queries against the underlying database.6 By simply querying the database for its tables and then extracting data from those tables, an attacker could have harvested the entire internal staff directory.6 While the data was limited to names, emails, and training progress, the ability to execute direct queries represents a fundamental breakdown in the application's security posture and provides a gateway for more advanced attacks on the organization's identity infrastructure.6
In a third case, AutoSwagger identified an unauthenticated API linked to a Salesforce instance for a large multinational technology company.6 The API contained a ByDate URL parameter that could be iterated to retrieve customer records in batches of 1,000.6 The research team found that they could potentially exfiltrate over 60,000 customer records, including full names, contact information, and detailed purchase orders.6 This type of exposure is particularly dangerous because it bypasses the sophisticated access controls typically associated with enterprise Salesforce environments, instead exposing the data through a poorly secured middleware API.6
The vulnerability research also extended into the DevOps toolchain, identifying a significant flaw in Octopus Deploy, a popular deployment automation tool.23 Designated as CVE-2025-0589, this vulnerability allowed unauthenticated attackers to enumerate Active Directory (AD) user information if the Octopus server was integrated with AD for authentication.23
The flaw existed in two specific API endpoints:
These endpoints were intended for administrators to search for users to assign roles, but due to broken authentication, they were accessible to anyone on the internet.23 A simple wildcard search allowed an attacker to retrieve JSON blobs containing email addresses, staff names, local AD usernames (DN and SAM), and User Principal Names (UPNs).23 While responses were capped at 1,000 records, an attacker could iterate through partial names to harvest the entire directory. This information is a "goldmine" for attackers, as it enables highly effective password-spraying and phishing attacks against an organization's internal estate.23
Vulnerability Profile: CVE-2025-0589
Details
Affected Product
Octopus Deploy (On-Premise versions) 23
CVSS Severity Score
6.9 (Medium) 24
Attack Vector
Network (Unauthenticated API) 25
Information Exposed
AD Usernames, Emails, Display Names, UPNs 23
Mitigation Strategy
Upgrade to version 2024.4.7065 or 2024.3.13071 23
Patch Release Date
January 14, 2025 24
The recurrence of these vulnerabilities is addressed by the Open Web Application Security Project (OWASP) through its API Security Top 10 project. The 2023 update to the list reflects a shift in the threat landscape, emphasizing that authorization failures are now the primary concern for security practitioners.11
BOLA remains the number one threat to APIs. It occurs when an API fails to verify if the user has permission to access a specific object instance.11
This category focuses on flawed authentication mechanisms that allow attackers to impersonate legitimate users.11
A new entry for 2023, BOPLA combines "Excessive Data Exposure" and "Mass Assignment." It targets the lack of validation at the field or property level within an object.11
BFLA occurs when sensitive administrative functions are exposed to unprivileged users because the system fails to verify the user’s role for specific actions.11
This category addresses the proliferation of Shadow and Zombie APIs. APIs tend to expose more endpoints than traditional web apps, making updated documentation and version control critical.11
Industry reports from Salt Security and Cloudflare provide a stark quantitative look at the challenges organizations face. These statistics highlight a widening gap between the scale of API deployment and the maturity of security controls.
API ecosystems are expanding rapidly, driven by cloud migration and data monetization. Approximately 30% of organizations experienced a 51% to 100% increase in APIs over the past year, while 25% reported growth exceeding 100%.3 Despite this, only 19% to 20% of organizations feel "very confident" in the accuracy of their API inventory.3 This lack of visibility is a critical vulnerability, as 58% of organizations monitor their APIs less than daily.3
Furthermore, the "Shadow API" problem is systemic. Cloudflare’s data shows that machine learning-based discovery consistently uncovers 30.7% more endpoints than what customers manually report.2 This suggests that for every three APIs an organization knows about, there is a fourth "ghost" API that is completely unmanaged.
A significant trend in API security is the move toward targeting authenticated sessions. Statistics show that 95% of API attack attempts originate from authenticated sources, indicating that attackers are not just trying to "break in"—they are stealing or purchasing legitimate credentials to exploit APIs from the inside.3 External-facing APIs remain the primary target, accounting for 98% of attack attempts, as they are the most accessible entry point into the corporate network.3
API Security Metric (2024-2025)
Percentage of Organizations/Incidents
Organizations experiencing an API incident in the past year
94% 33
Organizations suffering an API-related data breach (past 2 years)
57% 34
API attacks originating from authenticated users
95% 3
Organizations lacking continuous, real-time API monitoring
80% 31
Organizations that have delayed application rollouts due to API risk
50% to 55% 3
Increase in API-related breaches year-over-year (Verizon)
40% 7
The financial impact of these security failures is significant. Beyond the immediate costs of remediation (like the AUD 140 million spent by Optus), the average API security incident costs organizations roughly USD 4.45 million.8 For many small to medium businesses, these costs are existential, with 60% closing within six months of a major attack.8
The Optus breach and subsequent research have served as a catalyst for a global shift in regulatory enforcement. In Australia, the fallout has led to record-breaking penalties and a tightening of privacy laws that will serve as a model for other jurisdictions.
In October 2024, the Australian Competition and Consumer Commission (ACCC) secured a AUD 100 million penalty against Optus for unconscionable conduct.15 While the case focused on the exploitation of vulnerable consumers during sales and debt collection, it signaled a new era of aggressive regulatory oversight for large telecommunications providers. The court noted that senior management had been aware of deficiencies in their systems but failed to take prompt action to fix them.15 This "failure to act" is a recurring theme in major security incidents, where known risks are deprioritized in favor of operational speed.
The Office of the Australian Information Commissioner (OAIC) has launched significant civil penalty proceedings against Optus for its failure to protect the PII of 9.5 million Australians.19 The Commissioner alleges that between October 2019 and September 2022, Optus failed to take "reasonable steps" to protect personal information from unauthorized access, in violation of Australian Privacy Principle 11.1.19
The potential financial liability for such failures is immense. Under the updated Privacy Act, the Federal Court can impose penalties that are the greater of AUD 50 million, three times the benefit obtained, or 30% of the organization's adjusted turnover.35 Furthermore, a new statutory tort for serious invasions of privacy, commencing in June 2025, will allow individuals to sue organizations directly for reckless intrusions upon seclusion, even without proving actual financial loss.35 This shift significantly increases the legal risk for organizations that fail to implement robust API authorization controls.
As organizations integrate Generative AI and autonomous agents into their business flows, a new frontier of API risk is emerging. AI models do not operate in isolation; they depend on APIs to call tools, retrieve data, and execute actions. This has led to the adoption of the Model Context Protocol (MCP) and the deployment of MCP servers.36
The rush to operationalize AI agents has outpaced security oversight. MCP servers are often deployed without central management and are frequently exposed to the public internet, making them a new and high-value target for attackers.36 If an AI agent has access to an unauthenticated API, it can be manipulated through "prompt injection" to exfiltrate data or perform unauthorized actions. Salt Security’s research found that only 19% of organizations feel confident in their ability to monitor these new AI-driven API connections, creating a critical blind spot in the modern security fabric.31
To counter these threats, security providers are launching "Defensive AI" solutions. These include behavior-based user risk scoring and natural language interfaces like "Ask Pepper AI," which allow security analysts to query their entire API estate for risks using plain English.36 These tools use machine learning to differentiate between benign anomalies and actual attacks, identifying malicious intent with a claimed 92% accuracy.39 The goal is to provide "Illuminate Everything" capabilities—surfacing shadow, zombie, and unmanaged APIs across complex multi-cloud and hybrid environments.37
The current state of API security is defined by a systemic failure in basic authorization and inventory management. The research into S&P 500 firms and the devastating fallout from the Optus breach demonstrate that "complex" vulnerabilities are rare; most catastrophic failures stem from simple, unauthenticated endpoints that return massive volumes of sensitive data. The emergence of tools like AutoSwagger has democratized the ability to find these flaws, making them accessible to attackers of all skill levels.
To secure the digital future, organizations must move beyond reactive scanning and embrace a "Posture Governance" model. This includes:
The transition to an API-centric world is irreversible, but the current levels of exposure are unsustainable. As regulatory bodies impose billion-dollar penalties and individuals gain the right to sue for privacy invasions, the "governance gap" in API security will increasingly determine not just an organization's security posture, but its long-term viability in the global market. The lesson from 2022 through 2025 is clear: in the age of the programmable web, a single unauthenticated endpoint is a doorway to systemic failure.
