API Shield and discovery

what is API Shield?

Cloudflare excels in protecting http traffic, but a Gartner analysis revealed that we were falling short when it came to offering equally effective API protection. In the conception of this project, constant collaboration with the PM and Engineering org were key, since the work didn’t limit itself to UI design - but had to work in the world of API design as well.

Having a shared definition of success cross-org was paramount here, as workshops I led with the Engineering and PMs uncovered different goals and definitions of key elements. Even though we were only ready to bring forth a couple security solutions for APIs at that point (Schema validation and mTLS), it became clear that we needed to lay the groundwork for incoming endpoints to have the same definition regardless of what solution they would be for. This would ensure we could become a one-stop shop for security solutions.

If you go to a shop, regardless of what you want to purchase you still have to pay with the right currency. The same applies to API shield: to protect endpoints in multiple ways, the way we define and enter endpoints has to be the same.

Mind map showing path to deploy a new API shield through a shared definition of endpoints regardless of the security solution

 

During this work I had to really show the value of bringing design thinking closer to engineers early on, as many of the backend engineers were surprised to find themselves talking to me before they were officially committed to a ticket. Only through open and honest communication were we able to identify constraints early enough and stop ourselves from going down rabbit holes before we noticed we had cornered ourselves. Bringing both the UI and API design worlds closer together means we can have a consistent approach to our features regardless of how customers use our products. API only customers generate around 4x more volume in API calls, but there are at least 10x more dashboard only customers.

First workshop with Engineers and PMs to determine how we were going to tackle the work: and a 4th, not discussed previously option arising from it

 

What is API discovery?

It allows us to discover API traffic matching auth headers. Customers can see our automatically calculated rate limiting thresholds, see what endpoints are getting the most traffic and then they can then action upon it, and add it to a new or existing Shield. Endpoints can be added to an existing or new Shield, with the ability to apply different mitigation solutions to the entire shield or drill-down for specifics.

“this is already how customers mental model of API gateway works, so we’re on the right track. Ability to use switches to control what solutions are on/off”. - internal feedback

Co-creation is a great way to get to the innovation sweet spot, harnessing the power of the design, engineering and product teams throughout the product development process. Below, you can see some of the earlier iterations of trying to not only design the UI, but also how we would structure the API to work to match its usability.

 

STEP, JUMP, LEAP

A really effective way of condensing all of the learnings we were uncovering into what would fit the MVP was framing the work into a Step, Jump Leap framework. This meant that we could have alignment and set expectations early on not only for what we were doing for the MVP, but for where we were aiming to go from there.

 

So what is live?

What we has launched is a little different from where we want to go, at least for the Shield itself. While discovery of endpoints is now live and a game-changer, what we can do right now is recommend actual values for the rate limiting rule creation. It marks a strong step towards smart automation based on our understanding of our customers traffic, but there’s still a ways to go to be able to bulk add those to a security solution. This is because the much needed shared semantics for defining endpoints was not there yet on the backend side.

What we wanted the Shield creation experience to be like: a one-stop-shop where customers pick and choose their security solutions

The reality of what is live right now is fragmented, dividing discovery from each security solution.

 

The numbers don’t lie though: adoption of Schema Validation is soaring and mTLS is steadily high. While this was a big compromise, we are only now able to lay the groundwork for this to flow into the API Shield we envisioned because we took the time to create a shared definition of success cross-functionally early on, led by design.

Chart showing adoption of Schema Validation climbing since it's launch in March 2021
Chart showing the adoption of mTLS remaining steadily high since it's launch in May 2021

North star, future iteration we were working towards

What is live in the product