Future of API Security Reviews

A few years ago, I transitioned from being a pentester to a product security engineer/architect. This migration wasn’t as smooth as expected because, although both roles require similar technical skills, the nature of the work demands a different mindset. As a pentester, I would often begin engagements by examining all external (and later internal) facing API calls or other entry points, attempting to exploit them using various techniques like injection attacks. In contrast, as a product security architect, we start by either creating or reviewing a threat model, not by directly analyzing APIs.

As a new product security engineer, I initially searched for threat modeling templates that focused on architecture diagrams, data flow diagrams, asset listing, and then enumerating components using techniques like STRIDE. After conducting a dozen or so threat modeling exercises, I realized that while I was capturing the high-level aspects, I was overlooking crucial details, such as reviewing API contracts and the relevant external-facing attack surfaces

I began thinking about how to leverage my pentesting background to conduct more effective security reviews, and as expected, I focused on API security first. During my security review meetings, I would ask the engineering team to provide a list of all API calls related to the project, including any minor modifications to existing API calls. Once I received the list, I performed the  tasks below on the API endpoints as part of my security review.

1. Ask engineering team to provide list of all API calls

Having a list of API calls generally helped me gauge the complexity and scope of the product release. A comprehensive list of API calls was essential for initiating the next phase of the API security review.

2. Ask engineering to list all the parameters used by the APIs

In this phase, I review all the parameters accepted by the API calls within the product. I usually begin with external APIs, though the process is the same for internal API calls.

For each API parameter, I examine its type. Most of the time, API parameters fall into categories like query string, account or customer ID, limited text (e.g., 256 characters), freeform text, a configuration boolean, or date and/or time. I then assess the expected input and recommend that the engineering team use a library or regex to perform input validation on those fields to prevent injection attacks.

After this step, I analyze how the service handles each API parameter. After conducting a few dozen reviews, I developed an intuition for identifying critical API parameters. I could often predict whether a parameter is used for querying a database, fetching tenant information, or supporting critical business logic. This insight is the main value I gained from API contract reviews. Once I identified such an API call, I would focus more attention on ensuring it was thoroughly hardened and would recommend implementing detective controls to monitor any attempts to fuzz this API.

3. Ask engineering to provide the Auth mechanism on the API call

Although most API calls will utilize the organization recommended authentication and authorization controls, there are always exceptions. Some API calls might be utilizing legacy auth methods, or might be using auth controls asked by customers, or might be using something else prevalent in the industry. So I always check the auth methods and of the organization recommended auth methods are utilized, I would just ignore this task. If some other auth mechanism is used, I would then go ahead and ensure that the auth mechanism meets our security criteria.

4. Ask engineering to provide the rate limits available for the API call if available

This task is just ensuring that reasonable rate limits exists for the API calls and are enforced through something like API Gateway or through some mechanism.

5. Ask engineering to provide the output of the API call including the error messages

This task is just to ensure that error messages don’t return anything sensitive.

6. Ask engineering to provide the audit logs

This task is just to ensure that audit logs don’t capture any secrets, any critical information, or at worst any PII.

Future of API Security Reviews

After completing this work, I would document the information as a text field in our ticketing system, like Jira. As you can imagine, capturing the output of this API security review for a single task is straightforward, but making it easily consumable has always been a challenge. This workflow involves a lot of manual effort, and it becomes difficult to use when trying to review the last 10 assessments for a service to pinpoint when a specific change was made. Additionally, the API discovery process is manual, making this workflow unscalable.

I strongly believe that with new and emerging tools such as Escape Security in the market that can automate API discovery, provide clear visualizations of API parameters, and generate a list of security controls, API security reviews will become more scalable and repeatable. This will likely represent the future state of product and API security reviews.