Burp Suite User Forum

Create new post

OpenAPI Scanning - YAML File Import failure.

Will | Last updated: Jun 13, 2024 09:50AM UTC

Hi All, I am having issues importing an OpenAPI 3.0 Spec into the new API Scanner. It is a very large API, and consists of client data so I am unfortunately unable to share it. I have tried the following, but neither work: - Burp Suite Pro latest stable - Burp Suite Pro latest early adopter I have run my .yaml file through both "Vacuum" and "redocly" linters. Swagger's editor also show the spec as valid, as does Swagger's editor. The linters have the following warnings, but no errors: - Missing descriptions - Duplicate descriptions - Missing examples - Tags which aren't defined in global document tags - Missing tags - Unused components. How do I go about debugging this? Is there a way to access the logs in Burp Pro to see where it's failing when trying to parse the file? Could it be due to the size? Line count is approx 270,000. Otherwise worth noting, I've tried with the equivalent .json spec, but that fails too despite linking successfully. Any guidance is appreciated!

Will | Last updated: Jun 13, 2024 10:21AM UTC

Further context since I realised I missed it out, the exact error I get is: Couldn't read the API definition. Review the definition and correct any syntax errors. But from what I can see, there shouldn't be any syntax errors!

Will | Last updated: Jun 13, 2024 10:21AM UTC

Further context since I realised I missed it out, the exact error I get is: Couldn't read the API definition. Review the definition and correct any syntax errors. But from what I can see, there shouldn't be any syntax errors!

Will | Last updated: Jun 13, 2024 12:23PM UTC

Further note: When I imported into Insomnia, it would error due to some mismatched types for default values which I've since fixed. For example, if a "default" value is of type "integer", but contains a value: "1234" rather than 1234, it would error. Having rectified this has worked for Insomnia, but has made no difference with BurpSuite.

Syed, PortSwigger Agent | Last updated: Jun 13, 2024 02:24PM UTC

Will | Last updated: Jun 13, 2024 03:08PM UTC

Thanks Syed! I'll take a look. It does contain a valid server URL array, with one element and the server which is reachable from within Burp. The file is parsed okay by the OpenAPI Parser extension too, so it's just Burp's own parser that's the outlier for me at the moment. The server returns a 401 without any Authorization header, might this make a difference if Burp's attempting to reach out during parsing? Is there any way of me seeing what's causing it to error?

Will | Last updated: Jun 13, 2024 03:08PM UTC

Thanks Syed! I'll take a look. It does contain a valid server URL array, with one element and the server which is reachable from within Burp. The file is parsed okay by the OpenAPI Parser extension too, so it's just Burp's own parser that's the outlier for me at the moment. The server returns a 401 without any Authorization header, might this make a difference if Burp's attempting to reach out during parsing? Is there any way of me seeing what's causing it to error?

Syed, PortSwigger Agent | Last updated: Jun 14, 2024 07:33AM UTC

Hi Will,

If it has a valid server array with a URL, then the problem might be something else.

I am afraid I won't be able to help troubleshoot the issue without reviewing the API spec. Burp does not report the specific syntax error causing this, so you will have to compare and dig around manually.

I know it is not ideal, and I will put this as feedback, but for now, you will either have to look for the error yourself or share the spec with me.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.