Much has been written about modern application security tools and solutions from the provider’s perspective about their functionality and security features. When I was asked to write a blog about API Gateways and [API Security](), I felt it may be more useful to think about the subject from the user’s perspective. Specifically, what problem the app operators are looking to solve and with what tool? Although the topic is security-focused, it can also be helpful to discuss the need of Dev and DevOps as it is an increasing business imperative for any security operations not to slow down the applications and the application development process. ## From ADC to API Gateway. From WAF to WAAP. Operators of web applications have long been familiar with gateways and proxies. A load balancing proxy has been used by app operators to ensure performance and reliability of the application. Over time, more sophisticated proxies are made into Application Delivery Controllers (ADCs). To protect against website attacks (e.g. [OWASP Web Security Top 10]()) against the application, [Web Application Firewalls]() (WAFs) are attached in front of a typical ADC. WAFs are usually managed by security operators while the ADCs are managed by application operators though ADCs, arguably to implement security functions such as authentication and verification of incoming calls. A typical example is AWS’s Application Load Balancer (ALB) and WAF architecture. As conventional web applications are being replaced by API-driven applications, organizations are either converting their applications to leverage the flexible cloud native-architecture or front-ending their legacy applications with API gateways. API gateways, often deployed as part of an API Management solution, are replacing the role of ADC as the prime application-aware access gateway to an API enabled application. In the AWS example, AWS offers API Management Gateway service, front-ended by an Elastic Load Balancer (ELB) which in turn is protected by a WAF. Unlike the relatively simplistic HTTP protocol, [APIs]() are highly customizable. App developers can pretty much define their own APIs and change them in any way they want. API gateways are therefore designed to be a flexible and extensible platform, one that typically includes an extensive list of API management functions, such as data transformation, call routing and queuing, and custom message handling etc. Among these, security related features are typically limited to access management. Here are some specifics: * Verifying the identity associated with API requests through credential and token validation. This is not unlike an ADC that can authenticate web requests. * Determining which traffic is authorized to pass through the API to backend service endpoints. This feature is also very similar to an ADC managing access to web hosts/URLs. * Metering the traffic flowing through the APIs using rate limiting and throttling. As a platform, extensions can be added to most API Management gateways to implement other security features but they shouldn’t be treated as security offered by an API Gateway. As an ADC, most API Gateways in use are being managed by Dev/DevOps. As organizations are rapidly adopting APIs, web transactions that go through a Web Application Firewall (WAF) have also increasingly become APIs (according to [some estimates](), more than 70% of web traffic in a WAF process are APIs). It is worth pointing out that the vast majority of APIs are web APIs. Therefore, they can be affected by many of the same attacks against a web app. For example, injection attacks are common among the OWASP Web Top 10 and OWASP API Top 10. [Log4j injection]() attempts have been observed as often in web form input as in API inputs. In addition, bad bots have found APIs an attractive target as APIs are designed to enable automation without human intervention and therefore lacking some of the common anti-bot measures such as CAPTCHA challenges. A WAF with advanced bot protections against API abuses is therefore an important part of API Security. In recognition of the important role WAF plays in protecting APIs, WAF is changing its name to Web Application and API Protection (WAAP). Besides the WAF features such as Bot Protection, DDoS prevention, an API-specific feature implemented in today's WAAP is API Schema Validation. For a security operator who can obtain up-to-date API specifications, the operator can upload the specifications to a WAAP to validate API requests. The problem is that not many operators can find accurate API specifications, let alone having them updated by developers as they are changing their API implementations at an increasingly rapid pace. Consequently, in practice most operators today are implementing a WAF+API Gateway combination, not a true WAAP. ## More is Needed for Complete API Security It is increasingly clear that the WAF+API Gateway is, at best, incomplete. Many API-related data breach incidents are proofs demonstrating the potential risks posed by application specific, business logic or data level vulnerabilities. Take Broken Object Level Authorization, number 1 category of OWASP API Security Top 10, for example: an typical attack against a vulnerable application uses a series of API calls within an authenticated session, switching input request fields meant for user A to user B in an attempt to leverage user A’s session to get to user B’s data. All the calls in question would pass API Gateway authentication. The same calls are also in perfect compliance with the API schema. In order to protect API-driven applications from these application specific attacks, a new approach is needed to complement an operator’s WAF+API Gateway. Specifically, this new tool needs to automatically adapt to the APIs it is protecting, not only the schema/structure, but also, more importantly, the behavior of the applications especially that manifest itself as data flows in APIs. ## New Full Lifecycle API Security Tool for a Complete WAAP In order for the API security tool to learn the application behavior, the tool must first gain visibility into the APIs. As mentioned previously, most security operators do not even have an inventory of APIs and their specifications. Naturally, the first tool in a security operator’s tool box for API security is an automatic API inventory builder to discover all API endpoints, their schema, and data input/output of these APIs. It is critical for such a tool to be completely automatic as APIs change at a rapid pace. In addition, it is also critical for the inventory to include not just endpoints and schema, but also data which are the key assets that need protection. It is also critical for the inventory tool to function without dependency on developer input. Any dependency on developer input, such as an API specification, would significantly slow down the application development process. One easily overlooked factor in the implementation of API discovery is the deployment of the API inspection. For APIs already going through a WAAP, the operator can use it for API discovery if the WAAP in question has implemented advanced API discovery. For all the other APIs, operators must find tools that can be easily deployed to extract API calls for inspection. For example, Imperva’s API Security solution supports a wide variety of API sensors that can be easily deployed without change to codes, platforms, or the application packaging. With an extensive network of API sensors enabling always up-to-date API inventories, automatic anomaly detection and remediation actions can be implemented to protect APIs from sophisticated business logic and data level attacks. In summary, modern API-driven applications make it necessary to introduce a new API security solution to complement existing WAF+API Gateway in order to implement a complete WAAP. [Imperva API Security]() provides continuous protection of all APIs using deep discovery and classification of sensitive data to detect all public, private and shadow APIs to empower security teams to implement a positive security model. [Learn more](). The post [A Search for API Security in the Operator’s Tool Box]() appeared first on [Blog]().