Postman vs. Salt Security API Protection Platform

Postman is very good for easy entry into testing. Thanks to snippets it is easy to use, but also provides a lot [of] possibilities for testing thanks to the in-line editor. Easy to use on multiple environments (versioning) thanks to sets of environment variables. The Collections view can get very full with time and it is not possible to reuse or link requests so that they have always been copied and maintained manually for each copy if changes have to be applied.

Salt is highly recommended for anyone who wants to discover, monitor and protect their APIs against various types of attacks. Salt should not be used as a SIEM.

• It has opened a door for me to explore more out of it, as it is associated with so many APIs that I never felt any difficulty in finding the right API template, which are well organized and easily available.
• It is very secure to use and provides great services which are user-friendly.
• Due to this software I have got rid of the excessive emails and the slack channels, Now I am using my own private API and even it give me an option to produce my personal Postman’s API Builder from its Private API Network and this features has shared my excessive workload.

Incentivized

• PII identification in API traffic.
• Divergence between API traffic and documentation (swagger files).
• Potential attacks with information to take counter measures.

• Wherever you need to automate tests that involve database verification or rely on data from databases, Postman is less suitable.
• Postman's disc usage is extremely high, and it occasionally causes the computer to fade.
• It doesn't have the ability to generate random data. To achieve randomness in my tests, I've been working around scripts.

• The platform could have more options for exporting detailed data from attackers' dashboards.
• The Attackers dashboard could also have more options of filters in order to support the investigations of the attack.
• The OAS analysis could present a more detailed view of the found issues.

I think from a non-technical perspective there are a few things that could be more clearly labeled to better understand what is being asked for or where to add certain parts of the request.

Incentivized

There is a lot of in-depth documentation for Postman available online, including detailed guides with screenshots and videos. They provide example APIs for new users to explore while learning how to use the tool. Generally, bugs in the client are quickly addressed through frequent free updates. Community and professional support options are available - most of the time, the free/community level support is adequate

Incentivized

Previous to using Postman, I would either use browser tools directly, or write an in-house tool to send requests. Postman eliminates that need while providing a much better experience and more features. At the base level, Postman is as simple as typing in the address as you would in a browser. Authentication can be provided simply as well.

Incentivized

We tried controls offered by the IaaS providers but these were hard to manage and did not provide the visibility we wanted. We also protected APIs with a normal WAF but this was only helpful for assets we knew about and API attacks were not caught by the WAF.

• Postman is free (although there's a paid tier that offers more features) so using it for testing APIs comes with little to no risk (besides learning curve).
• The learning curve is a little steep for non-developer users, but developers should find it easy to pick up and use right out of the box, so to speak.

Incentivized

• Salt Security API Protection Platform has provided detailed information that is helping us to identify and investigate attacks in our environment