Skip to Primary Menu Skip to Utility Menu Skip to Main Content Skip to Footer
Noname Security Logo
/
/
REST API Security

REST API Security

Harold Bell
Share this article

Representational State Transfer (REST) APIs are so prominent today, that when people talk about APIs, they are almost always referring to REST APIs. 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 and sensitive data to external access, they are a favorite target of malicious actors. Naturally, organizations must invest in API security tools to protect their REST APIs. API security comprises a range of countermeasures which include encryption, rate limiting, access tokens and more. We’ll explore these security controls and how they can enhance your REST API security.

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.

The REST API 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 other APIs

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.

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.

Best practices to secure your REST APIs

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. TLS protects your information sent via your API through encryption of all messages sent through that API.

You can probably find TLS with the same acronym, SSL. If your URL begins with https rather than https://, you will know if your website supports TLS. Without TLS an attacker can intercept information from the transit server and access it without permission. All authentication methods are undermined by it. TLS requires certificates from certificate authorities that let the user know that your API is legal and protected.

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)

API authentication is critical barrier to keep malicious threats and bad actors at bay. 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.

Let Noname secure your APIs

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.

Harold Bell

Harold Bell was the Director of Content Marketing at Noname Security. He has over a decade of experience in the IT industry with leading organizations such as Cisco, Nutanix, and Rubrik, and has been featured as an executive ghostwriter in Forbes Technology Council and Hacker News.

All Harold Bell posts
Get Started Now (Tab to skip section.)

Get Started Now

Experience the speed, scale, and security that only Noname can provide. You’ll never look at APIs the same way again.