Creating a Safe Environment for

Under-Protected APIs
WHITE PA PE R

SHARE THIS WHITEPAPER

TABLE OF CONTENTS

ÐÐ
Background ................................................................................................................................................. 3

What are APIs?......................................................................................................................................... 3

ÐÐ
APIs in Modern Applications........................................................................................................................ 3

Rapid FaaS Evolution is Driving API Adoption ........................................................................................ 4

ÐÐ
Security Concerns of Distributed API Architecture...................................................................................... 4

The API Security Visibility Problem.......................................................................................................... 4

API Security Risks and Vulnerabilities...................................................................................................... 4

ÐÐ
Designing a Secured API Environment........................................................................................................ 6

Inline API Security Measures.................................................................................................................... 6

Radware API Security Technology........................................................................................................... 6

ÐÐ
References................................................................................................................................................... 7

CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 2

 BACKGROUND
The newly published OWASP Top 10 2017 Release Candidate introduces new application security risk protection
for APIs. This is a common concern as modern applications and services rely heavily on API integration and
communication. While on one hand APIs provide synergy and efficiency to business operations by simplifying
the architecture and delivery, on the other it introduces a wide range of risks and vulnerabilities. The combination
of growing adoption and security risks was the major driver for this new entry to the OWASP list.

What are APIs?

API (Application Programming Interface) is a set of tools and protocols used to develop application software.
This interface predefined request–response message system exposes reliable content and operation negotiation
(typically expressed in JSON or XML). The most common API protocol styles in modern architectures are REST
and SOAP. REST is by far the most common one.

Figure 1 - Distribution of API Protocols and Styles, based on directory of APIs listed at ProgrammableWeb, May 2016.

Publicly available APIs allow sharing of content and data openly between communities and applications.
ProgrammableWeb, one of the world’s leading information sources about Internet-based APIs, lists more than
17,444 APIs in its API Directory. This number has almost doubled during the past 4 years. Some outstanding
companies have built API businesses that match or exceed their original focus. For example, Salesforce
reportedly generates 50% of its revenues through APIs, eBay nearly 60% and Expedia a 90%.

APIS IN MODERN APPLICATIONS

APIs are being used in a variety of modern applications, where the most common examples are:

ÐÐ
Mobile applications
ÐÐ
Applications for IoT devices
ÐÐ
Embedding public and 3rd party APIs as external services into an existing application (e.g. Google Maps APIs)

DevOp environments, with the ever-increasing demand for continuous delivery, requires complete process
automation utilizing APIs across the board:

ÐÐ
Service provisioning and management (e.g. AWS API)
ÐÐ
Platform management apps
ÐÐ
Continuous delivery process automation

CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 3

Rapid FaaS Evolution is Driving API Adoption
Serverless architecture - or FaaS (Functions as a Service) - offers a model where the operational unit is a set of
function containers rather than a web server. These functions are APIs exposed for the client side application,
which may invoke these APIs upon relevant client side event. A simple example would be an IoT device that
would push a notification for a temperature reaching a predefined threshold.

In a FaaS architecture, the management of function containers is greater in complexity than just managing
lasting virtual machines. These function containers are created upon request and may disappear immediately
after being used. This approach simplifies the development process and reduces OPEX dramatically. It is
important to state that APIs are not tightly coupled with FaaS and are being widely used in other architectures
and with web applications.

SECURITY CONCERNS OF DISTRIBUTED API ARCHITECTURE

The API Security Visibility Problem

“
API vulnerabilities are hard to monitor and do
not stand out. Traditional application security
assessment tools do not work well with APIs or
are simply irrelevant in this case. DAST (Dynamic
Application Security Testing) and application
scanning tools, for example, cannot invoke the
API because they cannot generate well-formed
Since many Application
requests. Even if the tool knew whether the request
body should be a JSON or an XML and even has a Programming Interfaces
schema for the API, it is still difficult to provide the
data required to correctly invoke an API.
are mission critical and
Similarly, SAST (Static Application Security Testing)
tools don’t do a great job in scanning API code,
as in a typical API, third-party frameworks and
involve crucial business
libraries use custom methods to read a JSON or
XML document from the body of the HTTP request,
parse it, and pass the data into the API code. These
functionalities and
methods are different from one another and are
subject to changes, limiting the success rate of processes, API security
static tools.

When planning for API security infrastructure, has become a major

authentication and authorization must be taken into
account, yet these are often not addressed properly
in many API security solutions. As clearly stated in concern and challenge
the OWASP Top 10 2017 Release Candidate, “all the
different types of injection, authentication, access
control, encryption, configuration, and other issues
for organizations.

”
can exist in APIs just as in a traditional application.”

API Security Risks and Vulnerabilities

Web services such as APIs are vulnerable to all types
of attacks and threats against web applications:

CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 4

Vulnerability/
Attack Risk Protections/Controls
API transaction Confidentiality and integrity of - TLS is required to secure the communications between the client
manipulations data in transit and APIs for transport confidentiality and integrity of data in
transit.
TCP protocol tcp packet replay - Once detected the evasion attempt or the protocol manipulation
attacks and tcp packet fragmentation an immediate TCP Termination shall be taken.
evasion tcp packet reordering
techniques
HTTP protocol Manipulation of HTTP headers - HTTP protocol parsing and enforcement of HTTP RFC
attacks and (for instance - content-type protects against various HTTP attacks such as NULL byte
evasion header that is not aligned with injection, encoded attacks, HRS attacks, content-type mismatch
techniques the content sent in the body, etc.
etc). - Traffic normalization for evasion attacks detection. Peacetime
patterns shall be used as a reference as encoded attacks can
easily bypass security solutions.
- Message size policy enforcement - on HTTP message, body,
headers and JSON/XML element sizes - secures the application
against buffer overflow attacks, resource exhaustion and other
availability attacks on API infrastructure.
POSTed JSONs May eventually reach - Strong Typing and Positive Security model provide tight
and XMLs databases, leading to protection to API infrastructure. It will be impossible to generate
Injections injections. most of the attacks if, for example, the only allowed value type in
the JSON element is an integer with the value rage of 1 – 100.
- XML/JSON validity check and Schema Validation is
extremely important security protection. Types, value ranges,
sizes and order of XML elements must be configurable.
- SQL and no-SQL Injection protections through sanitizing and
validating user inputs and rule-based attack detection.
Insecure Direct Manipulation of state - Session and field protections against manipulation.
Object References information in parameter - Input validation in post transactions to detect injections of
value storing the account references.
number may allow access to
unexpected data.
Invalidated External entity embedding - Validation of user inputs for external domains in parameters and
Redirects malicious content in the submitted forms and form fields.
service or application.
Data Leakage Credit cards, social security - Data Leak Protection to make sure error messages and
numbers, passwords or any sensitive information is not leaking out to the potential attacker.
other sensitive data may leak Data structures and schemes of private information shall be
through the API response. recognized and guarded.
Also, 500 error messages may
leak architecture information
exposing server and data-
storing types.
Access Violations Unexpected users may - Access Control policy management with:
and abuse of APIs invoke APIs they should not o IP-based and geo Location restrictions when relevant
have access to or perform o Access restriction to particular APIs where, for example,
operations they should not be some APIs should be exposed for public access while others are
allowed (e.g. delete a license just for internal use.
vs. just generating a license). o Access restrictions to specific HTTP methods where the
set of operations that is allowed for some users is restricted for
others. For example, a user can generate a license but cannot
delete the license once generated.
DOM XSS An API client side vulnerability - XSS protection based on rules and signatures of known attack
that may lead to additional patterns. These rules and signatures must be continuously
attack vectors. reviewed and updated.

CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 5

 Session Session hijacking and - Session Management protection of the API key, which is
Management attack privilege escalation attacks. posted as a body argument or in the cookie.
Buffer Overflow Large JSON/XML - Strong Typing and Positive Security model provide tight
and XML bombs element values can affect protection to API infrastructure. It will be impossible to generate
performance, resource most of the attacks if the only allowed value type in the JSON
consumption and service element is an integer with the value rage of 1 – 100.
availability. - XML/JSON validity check and Schema Validation is
extremely important security protection. Types, value ranges,
sizes and order of XML elements must be configurable.
Bot attacks - Sophisticated application- - Limiting the number of attempts or identical actions per
layer bot attacks application or per API is an important protection against service
- Service Abuse abuse (for informational APIs), brute force attacks and denial-of-
- Brute Force service attacks.
- Scraping and data extraction
DDoS Attacks - Network and application- - DDoS protection – Attacks against applications can come in
based DDoS attacks mass, looking to disrupt services or retrieve database access.
- Distributed Denial of Service Some attacks focus on rendering the web application layer
unreachable, causing a denial-of-service state. In essence, one
HTTP request can lead the server to execute a large number of
internal requests. Multiple requests can consume all its resources.
There are few techniques to do that, including randomizing URLs,
API keys, and bypassing the application caching. Platforms
such as WordPress and Joomla - and even

DESIGNING A SECURED API ENVIRONMENT

Inline API Security Measures
WAFs and API gateways are the two major inline security tools for API protections. While API gateways do offer
usually authentication and authorization features, their HTTP and OWASP Top 10 protection offering is either
limited or absent. On the other hand, not all WAFs understand the differences between APIs and regular web
applications, even when both may use the HTTP RFC as a baseline. The obvious example is the HTTP method
use in REST APIs. While it is extremely unlikely for a web application to accept HTTP Requests with DELETE
HTTP method, it is a common practice with REST API call to support this method and other potentially risky
methods for web applications such as PUT.

Radware API Security Technology

Radware secures APIs as part of its flexible and scalable web application security solution and is recommended
by NSS Labs and ICSA Labs across on-premise, cloud, virtual, stand-alone or integrated, inline and out-of-path
deployments. Radware addresses all OWASP Top 10 security risks including the newly introduced A10 – API
protection. Beyond all the required protections discussed above, including SQL injection, broken authentication,
XSS, CSRF, DDoS, etc., Radware’s web application security technology features additional attack correlation
capabilities which allows blocking of repetitive attack sources by managing a penalty score for security violations
per source. Once an attack source reaches a predefined score threshold, it will be blocked.

Radware introduces a unique auto policy generation mechanism to reduce the complexity of keeping evolving
environments secure. Advanced machine learning algorithms learn XML and JSON structures and schemas
for enforcement as part of the validation phase and create a security policy based on those. Moreover, these
algorithms are able to track changes in the application and perform automatic updates in real-time, thus resulting
in an adaptive security model.

As part of Radware’s Attack Mitigation System, Radware’s WAF leverages DefenseMessaging - a unique
communication mechanism with Radware’s dedicated DDoS protection solutions - to provide best-of-breed
Layer 7 DDoS mitigation at the perimeter.

CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 6

 REFERENCES
https://www.programmableweb.com/api-university/understanding-realities-api-security

https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

https://medium.com/capital-one-developers/building-a-serverless-rest-api-in-go-3ffcb549ef2

https://techcrunch.com/2016/05/21/the-rise-of-apis/

http://blog.octo.com/strategie-d-architecture-api/

http://www.darkreading.com/application-security/what-do-you-mean-my-security-tools-dont-work-on-apis!!/a/d-id/1321050

http://readwrite.com/2011/05/26/soap-is-not-dead-its-undead/

This document is provided for information purposes only. This document is not warranted to be error-free, nor subject to any other warranties or conditions,
whether expressed orally or implied in law. Radware specifically disclaims any liability with respect to this document and no contractual obligations are formed
either directly or indirectly by this document. The technologies, functionalities, services, or processes described herein are subject to change without notice.

©2018 Radware Ltd. All rights reserved. Radware and all other Radware product and service names are registered trademarks or trademarks of Radware in
the U.S. and other countries. All other trademarks and names are property of their respective owners. The Radware products and solutions mentioned in this
document are protected by trademarks, patents and pending patent applications. For more details please see: https://www.radware.com/LegalNotice/

PRD-API_Security-WP-02-2018/02-US CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 7