OWASP ZAP Exploration by Postman Open Technologies
Postman Open Technologies doesn’t just serve as the face of our storytelling here at Postman, the team works with the community, customers, and analysts to map out the API lifecycle and help people understand what is possible with the Postman API Platform, open source solutions, and third-party APIs. And when something isn’t possible natively with Postman? We explore how to make it possible with a partner’s API or an open source solution. We’ve recently been working to push forward our platform capabilities in the area of security, and we agreed that the place to start with API security was with OWASP, and more specifically, their ZAP (Zed Attack Proxy) solution.
What is possible with OWASP ZAP
OWASP ZAP is an open source web application security scanner that is intended to be used by both those who are new to app security as well as professional penetration testers, providing a daemon mode that is controlled via a REST API. The Postman Open Technologies team wanted to understand if it would be possible to wrap OWASP ZAP with an API and provide a simple one-click way of introducing Postman users to API security. Our goal is to make something that we can use in demos and workshops, but also that is useful and deployable by our wider community.
We got to work playing around with what is possible, wrestling with the large scope of OWASP ZAP to see if we could achieve our objectives. We began with the intention of enabling the ability to scan an API using an OpenAPI definition, mimicking our approach to developing our OpenAPI Linting API using Spectral, and we are still wrestling with the possibilities of using OpenAPI to describe the surface area of the API being secured, or leveraging a Postman Collection that is generated from the OpenAPI. While OpenAPI acts as the source of truth for what is possible with the API, Postman Collections provide an opportunity to describe specific business scenarios with an API and even provide specific values to the path and query parameters. As our team explores the tradeoffs between using OpenAPI or collections, we are engaging with the community, customers, and across our internal teams to understand what is actually needed on the ground floor of operations when it comes to API security.
Joining forces with other Postman teams
As we were making our rounds with other internal Postman teams, we crossed paths with another team that was also exploring the potential of OWASP ZAP as part of the Postman API Platform. We met and shared what we were working on, and we learned that they were looking to not just bring OWAS ZAP security features to the platform, they were first looking to learn from, and contribute to, the OWASP community. This would ensure that Postman isn’t just building on top of open source solutions, but that we are also giving back. Postman Open Technologies came across an open GitHub issue in the OWASP ZAP community to enable the importing of Postman Collections and we decided we would start here when it comes to supporting the open-source API security community. It’s logical for us to begin with supporting existing requests for interoperability with our own platform, but because a collection is an open source format, it makes even more sense to help OWASP ZAP speak not just OpenAPI, but also Postman Collections. This would support both OWASP ZAP and the work that the Postman Open Technologies team is focusing on.
Paying it forward by investing in open technology
It remains to be seen what OWASP API security capabilities will be adopted natively as part of the Postman API Platform, but the coordination amongst teams within Postman really reflects the purpose of our Postman Open Technologies program. We are committed to investing in the open source frontline of the Postman platform, and we work to inform the community as well as the Postman roadmap about what is possible across the API lifecycle. This means direct investment in API specifications, as we do with OpenAPI, AsyncAPI, and JSON Schema, and also API tooling like Newman.
Whatever the possibilities for enabling open source tooling capabilities via collections that can be manually run by users in Postman workspaces, using runners, monitors, and pipelines provides endless opportunities for generating value, we need to deploy these solutions as simple APIs. Every open source solution that we deploy in this manner is a way we are paying it forward to our community by open sourcing the API—working to ensure it can be deployed in a multi-cloud way via AWS, Azure, and Google.
Postman Open Technologies is continuing our support of Spectral when it comes to the linting of OpenAPI, AsyncAPI, JSON Schema, and even of Postman Collections (see our OpenAPI Linting public workspace)—think about linting your documentation! We are also pushing forward with this multi-team investment in OWASP ZAP (see our project in GitHub) and exploration of other tooling around diffing, conversion, and other areas of the API lifecycle.
If you have feedback on how we can better leverage Spectral, OWASP ZAP, or any other open source API solution, we’d love to learn more. Our goal is to augment the Postman API Platform with the most useful, modular, and API-driven capabilities possible—and that means exploring all options. Our definition of a true API platform means that you should be able to integrate with any third-party service or open source solution you need, alongside the powerful native capabilities and integrations that are baked into the platform.
The future of the API lifecycle isn’t about any single API vendor or solution, or even a handful of them—it is about being able to leverage a diverse mix of API solutions as part of a single API platform that moves your enterprise operations in the direction you need.
What do you think about this topic? Tell us in a comment below.