Twelve Days of ZAPmas - Day 7 - API Testing with Postman and ZAP

If you’ve done any significant amount of API development, there’s a good chance you’ve used Postman. Maybe you use it every day, or perhaps you prefer Insomnia or Swagger UI or something else. We’re going to configure Postman to proxy through ZAP. It’s not difficult, because Postman is proxy-aware. I’ve written extensively about this before, using Burp as the interception proxy. But first, I’d like to recap why I approach it this way, especially given that ZAP has the ability to import an OpenAPI spec.

Why use Postman for this?

One pattern in testing APIs is that I want to make sure I have a “clean” version of the requests. Something that stays in a success state, and represents how the API is intended to be used. Using Postman through ZAP provides a level of separation where the normal requests are in Postman, and the tampering and fuzzing can occur in ZAP. The other thing to note is that when I imported an OpenAPI spec into ZAP, it tried to immediately perform automated interactions with it, but didn’t present any real UI for viewing and reissuing those requests. Postman provides a familiar tool geared towards managing those requests, and I use it for APIs essentially the way I use the browser for web apps.

Update: As Simon quite correctly pointed out in his post, those automatic requests populate the sitemap and history, which can be used for replaying, tampering, and fuzzing. My intended meaning was that there isn't a dedicated UI for browsing the contents of the spec, including type definitions and description fields, as you would see in Postman or Swagger UI. You could certainly work entirely within ZAP, but I find Postman's UI brings some quality of life improvements when trying to grok an unfamiliar API.

Proxying Postman through ZAP

1. Download Postman if you don’t have it already. It’s available at: https://www.postman.com/downloads/
2. Launch Postman. The first time you launch it, you will land on a screen prompting you to create an account. There’s a subtle link at the bottom of the page to skip that step.
3. Use the gear icon on the top-right corner of Postman to open the menu, and choose Settings.

6. You’re done. Close the settings, and Postman should proxy through ZAP.

I won’t go back into the basics of working with Postman here, but I did cover that in a fair bit of detail in the Better API Penetration Testing with Postman series.

We also go deeper into API security, flaws, and testing techniques in our Professionally Evil API Testing class available via Antisyphon Training.

In Summary…

I’ve found that the best way to work with APIs is with a dedicated client outside the interception proxy. Postman is robust and mature, and proxy aware, plus has options specifically for supporting SOAP and GraphQL, which makes it a great candidate. But I’ve also proxied Insomnia, and I’ve used Swagger UI and similar web-based API clients within a proxied browser. These are all valid options, and if you’re already using an API client to test your API during development, the best option is probably to use the same API client. If you’re testing with curl scripts, use curl’s -x argument to proxy it through ZAP. But if you don’t have anything established, or you’re having to construct requests just from documentation, Postman is a great option. In either case, once a request is proxied through ZAP, you can use the Request Editor and the Fuzzer to look for missing authorization checks and injection flaws.

Check out day 8 for a look at ZAP's spidering capabilities.