Introducing the API Security Workshop Learn More  

REST API Security 

Property 1=REST API Security


Representational State Transfer (REST) APIs are so prominent that today, when people talk about APIs, they are almost always referring to REST APIs. However, REST APIs are not the only APIs in use, nor are they the only mechanism for achieving the kind of application and data integration they enable. However, on the web, they are the most popular form of API and receive the bulk of developer and IT department attention. They also get a lot of attention from hackers. 

For a variety of reasons, securing REST APIs is a critical undertaking for enterprise cybersecurity practitioners. Because APIs expose applications, as well as sensitive and critical data, to external access, they are a favorite target of malicious actors. Naturally, organizations must invest in REST API security that comprises a range of countermeasures which include encryption, rate limiting, tokens and more.

What is a REST API?

The REST architectural style was defined in Dr. Roy Fielding’s dissertation published in 2000. The goal of this paper was to define a uniform and consistent architectural approach for machine-to-machine communication on the web. A REST API is an API that uses the REST architectural style to send and receive data and procedure calls. A REST API also needs a transport protocol and a programming language to function. REST APIs communicate over HyperText Transfer Protocol (HTTP), and the preferred data format for messages transmitted is JavaScript Object Notation (JSON). Thus, the term “API” almost always refers to a REST API that uses JSON over HTTP.

REST became the predominant mode for APIs for several reasons. For one thing, it is free and standards-based, so there are almost no barriers to its adoption. RESTful programming is also “stateless,” which makes it easy to manage. A RESTful interface is uniform. Query parameters are standardized. As a result, it is quite easy for an entity that creates an API to publish instructions for developers to use when invoking the API, e.g., Here’s how to get data from the API, which will be returned in JSON. Other types of responses are possible, too, including Extensible Markup Language (XML), documents, and images. 



REST APIs vs others

REST APIs are not the only type of API in use for the interchange of data and procedure calls between systems. An API is any interface that connects software, data sources, or hardware. APIs are employed for an extensive array of use cases. Connecting a printer to a PC requires an API, for example. Or when a mobile banking app needs to get a user’s account balance at an investment firm, it will invoke that firm’s API to retrieve the user’s balance. 

APIs are extremely widespread. A website that has a map, for instance, will use the mapping service’s API to generate the map data. If the site displays stock market quotes, those will also come from an API, as do weather reports. Prior to 2000, most integrations between applications were proprietary or custom-coded. If one wanted an application written in PASCAL to retrieve data from a software program written in COBOL, it was almost always necessary to build an interface from scratch—or purchase a costly piece of “middleware” that would then need to be maintained. 

By 2000, IT managers had had enough of this expensive, cumbersome approach to application integration. Spurred by the rise of the Internet, which is based on open standards, industry leaders like IBM, Microsoft, and Oracle got together and agreed upon a set of open standards for connecting software applications. These were known as the Web Services standards. 

The main API in the Web Services standards was based on Simple Object Access Protocol (SOAP), a form of XML. SOAP web services, which are comparable to REST APIs, became the core of epoch-defining new platforms like Microsoft .NET, IBM WebSphere, SAP NetWeaver, and Oracle Fusion Middleware. They triggered an entire generation of standards-based application integration. 

Over the ensuing years, software makers and enterprise architects developed more streamlined and easier-to-use open standards, of which REST has emerged as the clear winner. However, there are still many SOAP web service APIs in use today, as well as those powered by other formats like GraphQL, an open-source data query and manipulation language for APIs.


Securing the REST API

Without proper safeguards, REST APIs represent an extensive, vulnerable attack surface. While organizations could previously rely on “security through obscurity,” wherein hackers would have to work hard to find data inside a network with an API, the organization literally publishes instructions on how to find the data and steal it. 

REST API security practices have matured. The most common and effective countermeasures include:

  • Secure channel—The communication channel for API calls and responses needs to be secure. A best practice is to use Transport Layer Security (TLS), which used to be known as Secure Socket Layer (SSL). A TLS certificate uses end-to-end encryption to protect API data and access credentials while they are in transit.
  • API keys—API keys are unique strings that function as API access credentials. They are used for authentication of clients calling on the API.
  • Tokens—API tokens are unique digital identifiers that authenticate API users. Tokens make it possible to avoid burdensome authentication processes like two-step verification and single sign on (SSO). With a token, API admins can grant and revoke API tokens from API users, providing control over API access. Tokens are usually issued by the server hosting the API for use by client-side apps. The token mechanism differs from cookie-based session management in that it’s normally stateless. There is no need for the server to store session details—making it easier to scale out infrastructure that uses APIs.
  • OAuth 2—This is a secure standards-based authentication mechanism based on tokens. It works for API user authentication and authorization. 
  • JSON Web Token (JWT)—A JWT is a digitally-signed authentication token that contains data about the API user in JSON. The advantage of a JWT is that it can hold more data than an API key.
  • Rate throttling—APIs are targets of Denial of Service (DoS) attacks. An attacker can flood an API with requests and cause it to shut down. To prevent this from occurring, an API security tool can implement rate throttling, e.g., shutting off access if a client tries to invoke the API too often in a given time period. 
  • Integration with IAM—It is possible to establish user identities for API clients by integrating API management with Identity and Access Management (IAM) systems. This way, an admin can gain control over who is permitted to use an API, which prevents unauthorized access.
  • Validation of parameter-based query inputs—Hackers may try to trick an API by modifying JSON request data and URL parameters. By validating these parameter-based inputs, it is possible to stop this type of attack before it starts. 
  • Whitelisting of permitted HTTP methods—This countermeasure establishes a list of permitted HTTP methods for the API, e.g., POST, GET, PUT. By default, this control blocks methods that should not be allowed by a public API user, such as DELETE. 
  • API monitoring—It is critical to keep track of API usage and performance, ideally in real time. By monitoring APIs, admins can flag anomalous behavior that could indicate an attack in progress. This might include logging failed requests and looking for suspicious patterns.

REST APIs are here for the duration. For better or worse, they’re how most applications interoperate with data sources and one another. They’re rich targets for bad actors, though, so they need to be secured. Fortunately, REST API security is definitely achievable.  A host of proven controls and countermeasures make it possible to enjoy the benefits of REST APIs without exposing the API hosting organization to excessive risk.