The reason I stopped using Postman for API Pentests

I’ve been a proponent of Postman for a number of years. I’ve written and spoken about using it in the API pentesting toolchain, proxied through your interception proxy (Burp/Zap/etc). This lets you use Postman as your clean version of the API calls, while tampering and fuzzing is delegated to the interception tools. Postman continues to be an effective tool for developers testing API interactions, always their target audience. However, the direction their product suite has taken in the last year, and the roadmap for the near future, make it poorly suited for consistent usage on penetration testing engagements. The changes are detailed in a post on their blog from the past May.

What’s the problem?

The thrust of the issue is that crucial functionality is being removed from the offline Postman client as the Lightweight API Client (I’ll refer to it as the LAC here) becomes the only means of using Postman without an account. You can access the LAC through an updated Postman app today, the image below shows the new introduction screen with the option.

The choice not to use an account was intentional as discussed in my earlier blogs about using Postman, because the account’s purpose was to sync collections of requests to Postman’s cloud service. This is a convenient feature for developers, who want to share and collaborate on Postman collections. As a security consultant performing a pentest, it’s simply not acceptable for me to sync details of my client’s API specification to a third-party cloud service. I also note that this is not necessarily limited to routes and request structure, as collections can contain variables as well, including authorization tokens and base URLs (often meaning internal or external hostnames).

The LAC can still be proxied through my interception tools, and can still be used to construct requests. But it does not have the ability to import Postman Collections or OpenAPI specs. As a matter of fact, the only import it supports is from a pasted cURL command. Other import functionality that now requires a Postman account, meaning that the imported collection will be cloud synchronized on my account. We regularly receive OpenAPI specs, Postman collections, or GraphQL schema files to speed up our setup for API tests, which is especially crucial for large APIs. The image below shows the current import dialog in the LAC.

Can you use an account, but disable the syncing?

The short answer, per Postman’s current documentation, appears to be no. The LAC is only offering for folks who do not want to sync their collections. The relevant excerpt from the documentation is pictured below.

As of now, there is also no offering for on-prem synchronization in place of Postman’s hosted solution.

What are alternatives to Postman for API pentesting?

I’ll present some options for alternatives further down, but before I do, I want to be clear that this is not intended to be a broad complaint about Postman’s direction. They are a commercial entity, and those of us using the tool without accounts have not been paying anything. It makes perfect sense for them to cater their product offerings to their paying customers, and not to factor in our use case. I think the product changes do add some new risks for organizations using Postman as a developer tool, which they should analyze before deciding whether to accept. For us pentesters, this does raise the question of what tool should fill Postman’s role in the toolchain for pentesting APIs now. Let’s take a look at a few established options:

1. Insomnia: Made by API Gateway stalwart, Kong, I’ve written on setting this one up before. Insomnia is still a strong competitor in the space, and a popular option with many developers. I found it close to feature parity with Postman a few years ago, but overall preferred Postman’s scripting interface.

2. Hoppscotch: A web-based solution with options to self-host the app. Because this option runs in the browser, usage would be to run it locally and access its UI via your proxied browser. It seems to have a lot of potential for advanced use-cases, but I need to explore it further. A demo environment is hosted here.

3. Swagger UI: A well-established web-based option as well, Swagger is synonymous with API specifications. We regularly see Swagger UI used for hosting public API documentation, sometimes private documentation as well. It can be loaded in the proxied browser for usage in the toolchain. Swagger products have been under SmartBear's umbrella for the better part of the past decade.

Next Steps

As we round out the year, I will look to do a deeper dive into easily setting up the Hoppscotch and Swagger UI options, as part of your pentesting toolchain. I will also look to update the Insomnia blog, as it’s been a few years since I wrote it. There are plenty of valid options to consider, it’s just a matter of finding which one will best support penetration-testing activities.  The main considerations are as follows.

• The ability to import an OpenAPI spec and a GraphQL schema is a must.
• It needs to be easy to manage requests within the app. Basic functionality like making a copy of a request and editing it should be present.
• We need to be able to proxy through whichever interception proxy we choose. A browser-based solution or a proxy-aware application are ideal.
• We must have support for variables that are substituted into requests.
• Ideally we would have scripting capabilities for common authentication flows, for example extracting a value from a JSON response and updating a variable with it.
• Being able to import Postman collections might help for clients that choose the Postman product suite. It’s possible that they’ll be able to grant some level of access to their Postman Cloud environment as well, but I am currently unsure how much help that will be for performing penetration tests.

I’ve always been happy to share what has worked for me, and will continue to do so right here on Professionally Evil Insights as I try the available Postman alternatives.