Broken Authorization in APIs: Introducing Autoswagger

TL;DR 

• Intruder has released Autoswagger, a free tool you can use to check your APIs for simple authorization vulnerabilities
• These basic weaknesses are still very common, and very easy to exploit for even unskilled attackers
• Re-scan your APIs after each development iteration. Don’t assume that new endpoints on an existing API have been properly secured.
• Continuously monitor your systems to detect self-documenting APIs. Do not publicly document your APIs unless you can’t avoid it

Application Programming Interfaces (APIs) are a core part of most modern application stacks. They often govern highly sensitive data and are one of the most exposed parts of your infrastructure. Perhaps surprisingly, some of the most common vulnerabilities in APIs are also some of the easiest to exploit, and glaring mistakes such as endpoints governing sensitive information requiring no authentication whatsoever are still common.

“These vulnerabilities are so simple to exploit, that it would be possible to teach a non-technical user how to exploit them in a single day.”

Arguably the highest profile breach resulting from a simple API authorization weakness was that of Australian telecoms company Optus back in 2022. They were asked for ransom after millions of customer records were extracted, and ultimately set aside $140m AUD to pay for the fallout.

Three years on, the Intruder security team ran a research project to explore the prevalence of these glaring vulnerabilities in 2025, and found a range of critical weaknesses on APIs exposed to the internet. We focused on the same authorization weaknesses that caused the Optus breach, both of which have ranked in the top 5 of OWASP’s API Security Top 10 project since its inception. Specifically, authorization weakness in APIs: Broken Function Level Authorization (API5:2023) and Broken Object Level Authorization (API1:2023).

What is Autoswagger?

Intruder developed a free tool (Autoswagger) which can be used to automatically scan APIs and discover sensitive endpoints where the application fails to check for a valid API token. It parses OpenAPI schemas to discover and test each endpoint one by one to look for authorization weaknesses.

Using Autoswagger, we scanned Bug Bounty targets to find real examples of these weaknesses, which we showcase below to emphasise the importance of regular API testing and the dangers of self-documenting APIs. Alongside this post, we have made Autoswagger available for free on GitHub, so you can use it to scan your APIs for these weaknesses and discover if you have exposed APIs that are affected.

Proving Grounds - Bug Bounty Examples

We put Autoswagger to the test against targets from several large Bug Bounty programs, and scanned for vulnerable APIs at scale. We’ve detailed some of the findings below to give you a feel for what real authorization weaknesses look like:

Exposed Credentials in Config Endpoint (Microsoft MPN)

Our first example is quite stark, in that it was simply an endpoint named ‘config’ which exposed credentials and API keys for several Microsoft Partner Program data stores. It may be hard to believe, but vulnerabilities as simple as exposed credentials with no proper checks for authentication are still common in 2025:

‍

Amongst the various sets of API keys and credentials in the response was a valid set of credentials for a Redis database containing the personally identifiable information (PII) of Microsoft Partners and the courses and certifications they had undertaken:

The full path where this vulnerability was discovered (/1/dashboard/mpn/program/api/config/) is too complex to guess. Even with an extensive and recursive brute-force, it’s highly unlikely that a path six layers deep would ever be discovered, even by a determined attacker. 

Of course, the endpoint should have had proper checks to ensure the user is authenticated, but it’s worth noting also that this vulnerability likely would not have been discovered if the API didn’t expose its OpenAPI schema. The key takeaway is that exposing documentation for your API effectively increases your attack surface, and as a defense in depth measure, you should not expose API documentation unless it’s a business requirement. 

60,000+ Salesforce Records with PII Exposed at a Large Multinational Tech Company

‍Our Autoswagger bug bounty sweep also found a large number of customer records exposed on an API that appeared to be linked to a Salesforce instance for a large tech organisation:

Data exposed included typical SalesForce information, such as customer name and contact details, along with the product lines ordered.

Unauth Access to Execute Query Endpoint at a Multinational Soda Company

Another vulnerability discovered using Autoswagger was in an API running in Azure Functions for a well-known multinational soda organization. The API was for an internal staff training application, and the vulnerability allowed an attacker to run entire SQL queries against the database. Exploiting this weakness was as simple as querying the database for its tables, then querying the data from those tables to extract information.

POST /api/Misc/ExecuteSafeQuery HTTP/2
Host: *******************.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Content-Length: 39

{"query":"SELECT * FROM ****_Users"}

Although the database only included information such as the name, email address, and training information on internal staff, this could still be invaluable information to an attacker targeting this organization, as they would have a list of valid staff email addresses and information about their training progress. This could be used to mount a phishing campaign posing as HR staff against those users, with real information that could gain the staff member’s trust. 

Azure Functions APIs do not expose their documentation by default, but the developer had deployed an extension intended to expose the API schema. It’s possible that the schema was exposed so that it could be consumed and interacted with by another service, but there was no clear need for it to be internet-exposed, considering the connected application was for internal staff use.

Unauthenticated Access to Active Directory (Octopus Deploy)

Finally, Autoswagger also discovered the weakness detailed in this post we made back in March (CVE-2025-0589). The bug allowed an unauthenticated attacker to enumerate Active Directory (AD) user information if AD was integrated with the Octopus Deploy server. 

These are just a few of the examples we came across to give you an idea. We also found medicaid data for patients in a US state, API keys for deepseek, and many sets of plaintext credentials and keys for applications and APIs - all just sitting there, fully exposed and documented ripe for the taking!

How Autoswagger Works

Detect, Enumerate, Parse

Autoswagger starts with a detection step to find API schemas in a range of different formats. It uses a list of common locations for OpenAPI and Swagger documentation pages, and sends requests to each host to find valid schemas to parse. This includes direct parsing of simple OpenAPI schema files, and several common Swagger formats:

Once a schema is found, the tool parses the specification and generates a list of endpoints to attack, taking into account each endpoint definition, its parameters, and expected datatypes.

Scan Endpoints

Once the schema has been parsed, the tool scans to each endpoint using the required parameters and types from the documentation. The tool is looking for endpoints that result in a valid response, rather than HTTP 401 or 403 for example, as we would expect from an API that is properly checking for a valid API token.

Autoswagger can also be configured (using the --brute flag) to attempt to bypass endpoint validations, where the API expects specific information for certain parameters. This aims to cover cases where an endpoint expects not just a string, but a specific type of string, and has validation steps which reject strings not of that type. For example where an API requires that a string is a valid email address, or a type 4 GUID.

Output Vulnerable Endpoints

Each endpoint that gives a valid response is then analyzed for PII and sensitive information such as credentials. Endpoints which were missing authentication are output, along with whether sensitive information was discovered in the response:

The risks of automatic documentation 

Automatic documentation is a phrase that is music to most developers' ears. No developer in their right mind wants to spend hours labouring away at documentation, especially when their API is changing on a regular basis. The burden of keeping documentation up to date can be almost a full-time job in itself.

‍

However, when it comes to APIs, documentation is a must-have for an attacker looking to exploit an API, to the point that if an attacker doesn’t have full documentation for an API they most likely wouldn’t even bother to try attacking it, because other angles of attack would offer a path of lesser resistance. Though it is technically feasible to fuzz API endpoints, paths, and parameters, the effort involved is somewhat akin to trying to brute force a long password. It’s simply not worth the effort.

Of course, security by obscurity is not a replacement for regular API testing, and simply hiding your documentation does not provide an alternative to vulnerability scanning, pentesting, and fixing your weaknesses. But if your API does not explicitly need to be publicly documented, you should consider it an attack surface risk to do so, regularly scan your APIs, and remove all documentation that is not required. Intruder presents exposed API documentation as an attack surface risk:

The majority of the vulnerabilities we discovered as part of this research were for APIs intended for internal use. There was no clear need for each API to be publicly documented, or internet-exposed. It may be time to take a look at your own digital estate and determine if you have APIs which also fall into this category!

Get always-on vulnerability management for APIs - start a free trial of Intruder to get started today.