How good is Burp’s API Scanning?

PortSwigger recently wrote a blog post on API Scanning with Burp Suite. It explained how Burp’s crawler parses OpenAPI documents and how it will create sample HTTP requests for endpoints mentioned in the OpenAPI doc. I even covered that in my newsletter.

I created a demo environment using the Vulnerable API (vAPI) project to see Burp’s API scanning capabilities over real-world projects. vAPI is an intentionally vulnerable API implemented using Python Flask.

(If you want to see manual analysis and exploitation of vAPI by Matthew Valdes, please check out my write-up).

For this example, I am using jorritfolmer’s vAPI fork. This forked version, unlike the original, is implemented using Python Flask + Connexion and exposes OpenAPI JSON doc at the /openapi.json endpoint.

OpenAPI document at /openapi.json

Also, the forked version has some disadvantages:

• it doesn’t support XML payloads (meaning XXE is impossible)
• a GET endpoint is missing (which deleted an information disclosure issue)

Importing the API definitions to Postman gives the following requests:

OpenAPI document loaded in Postman

The exposed API endpoints in OpenAPI doc are:

(GET) /

(GET) /uptime

(GET) /uptime/:flag

(POST) /user

(GET) /user/:user

(POST) /tokens

(POST) /widget

Now let’s see if our vAPI environment meets API Scanning’s prerequisites.

PortSwigger’s API scanning documentation says the OpenAPI must be of 3.x.x version, and the API definition must not contain any external references. Luckily the OpenAPI doc from the vAPI project follows both — it uses OpenAPI 3.0.1 and doesn’t have any external references.

Active scanning vAPI

I opened the / path of vAPI and found the following JSON output.

vAPI status page

Let’s assume that Burp’s active scanning will automatically discover the /openapi.json endpoint and then parse the document to add more paths.

Goto Target ->Site map -> Right Click on target -> Actively scan this host

Active scan of vAPI endpoint

The audit finished pretty fast and didn’t find the /openapi.json endpoint. But the active scanner bruteforced multiple query parameters for the known endpoints.

Logger++ output of scanner

Discover content and Active scanning vAPI

Our above assumption was wrong. Maybe that’s because vAPI doesn’t have any webpages / URLs mentioned that link to OpenAPI doc.

Now let’s see if Burp can discover this endpoint with its Discover Content option.

Goto Target -> Site map -> Right Click on target -> Engagement tools -> Discover content

I launched the discover content session with the default configuration without any custom wordlist.

Once the discover content session is complete, we see it has found two endpoints: /console (with different query params) and /user.

Discover Content output

Burp has found a /console endpoint that’s not documented. The /console endpoint exists because the Flask app runs in debug mode. The debug mode is indeed an issue, but it’s because of the server, not API.

It hasn’t found the openapi.json file yet.

Explicitly adding openapi.json to Burp Crawler & Scanner

Maybe passing the OpenAPI file directly to Burp’s crawler and scanner might work.

Goto Dashboard -> New Scan -> Paste the URLs -> Click OK.

I will use the default configuration of Burp Scanner for the scan.

Explicitly crawling and scanning openapi doc

Yaay !! It did find new endpoints and find issues with them.

Active Scan output

Active Scan status

The endpoints /tokens and /uptime are new, and Burp seems to have fetched them from the OpenAPI doc. Burp still hasn’t found endpoints like /uptime/:flag, /widget, /users, etc.

The detection phase was better than before. Let’s see if the Burp scanner has found all vulnerabilities.

vAPI’s documentation says that the project has the following vulnerabilities:

• Insecure transport
• User enumeration
• Authentication bypass
• No input validation
• SQL injection
• Weak session token crypto
• Poor session validation
• Plaintext Storage of secrets
• Command injection
• Regex denial of service
• Cross-Site Scripting
• Missing security headers

From the above vulnerabilities, Burp Scanner cannot find the following vulnerability classes (according to Burp Scanner’s Issue Definitions):

• Information Disclosure (unless the information is email addresses, private IPs, SSN, credit card numbers, etc.)
• Regex denial of service

It’s hard to give a general context of a user/object, roles, & permissions to security scanners. So security scanners, in general, can’t find issues like:

• User enumeration
• Plaintext Storage of secrets
• Authentication Bypass (As SQLi in can be used to bypass the requirement of admin token to create user)

However, Burp Scanner found these issues:

• Insecure transport (Issue: Unencrypted Communications)
• No input validation (Issue: Input returned in response — reflected)
• Cross-Site Scripting (Issue: Cross-site scripting — reflected)
• SQL Injection (Issue: SQL injection)

Vulnerabilities detected

What am I trying to say?

Let me summarize.

Suppose you want to scan an API server that exposes OpenAPI doc; Burp Scanner parses the OpenAPI doc only when you explicitly specify the file path while starting Active Scan. Even if it parses the OpenAPI doc, it misses out on specific endpoints (for reasons unknown) and required headers. Not supporting additional HTTP headers is a known limitation of Burp Scanner for API testing.

Burp Crawler’s job of crawling API endpoints from OpenAPI doc is not bad, but there’s more to improve. Burp Scanner seems to do an excellent job on scanning independent API endpoints (if found from OpenAPI docs, like search, login, etc.), but not on logically dependent APIs (like delete API works only after create API was successful).

For security engineers:

If you have any current automation to test APIs (like Postman Scripts -> Burp Suite -> Burp Scanner / Custom Extensions), don’t replace the automation with only Burp Suite. Instead, if you are interested, run it alongside your existing automation. Don’t forget to check Burp Suite’s limitations for Scanning APIs. Remember, Burp Scanner can scan for vulnerabilities on independent APIs, not on “logically dependent” APIs.

For bug bounty hunters:

If you found an endpoint that discloses OpenAPI docs, explicitly “crawl and scan” the endpoint. You might end up finding something juicy. Even though Burp doesn’t crawl and load all APIs, something is always better than nothing. If you want to understand APIs’ logic, load the OpenAPI doc in Postman and manually test them.

Originally published at https://burpsuite.guide/blog/how-good-is-burp-api-scanning

Signup to my newsletter for latest articles, reviews, offers and biweekly newsletters on new Burp extensions.