Introduction: Why We Need to Secure REST APIs

Understand the evolution of web services and the need for enhanced security measures.

We'll cover the following

REST

Representational State Transfer (REST) is an architectural style first described in Roy Fielding’s Ph.D. dissertation, “Architectural Styles and the Design of Network-based Software Architectures.” It is not a protocol itself but relies on one for communication—usually HTPP protocol. So, we need to understand how REST APIs can be better secured.

Protocol for REST

A protocol in computer science is a set of rules or procedures for transmitting data between electronic devices. REST APIs typically use the Hypertext Transfer Protocol (HTTP) protocol.

History

As the internet began to grow, the need for communication between different devices and applications written in multiple technologies and residing on different servers began to grow. So, the need for standardization of the communication process and the need for defining a protocol also grew.

Web services evolved to provide overall better communication across different devices and server—regardless of the technology used.

Server vs. client rendering

Server-side rendering

Initially, servers used to construct HTML directly and send it to the client. The client would then use it for rendering.

Client-side rendering

With the introduction of web services, servers only sent raw data and the client would build the HTML and then render it.

Of the many protocols developed for web services, Simple Object Access Protocal (SOAP) and REST have stood the test of time. While there has been a constant debate on whether to use SOAP or REST, the ability of REST to use the underlying HTTP protocol itself and build on it has given it an edge in some scenarios.

SOAP typically used Extensible Markup Language (XML), which is a little bulkier compared to JavaScript Object Notation (JSON) representation of data. This less bulky nature of JSON helps to optimize the usage of network bandwidth and also helps to give a boost to REST. That said, REST supports a wide variety of data formats apart from JSON.

With the increased usage of REST comes the increased security attacks on REST APIs. So, we need to secure them.

Architectural constraints of REST

Any REST API has to conform to specific architectural constraints. When we design a REST API, it has to meet the below architectural constraints:

  • It should have a uniform interface.
  • It should be stateless.
  • It should be cacheable.
  • Client-server
  • It should be a layered system.
  • Code on demand (optional)

Security is a concern across all the constraints that the REST API has to consider during the design and implementation phases.

Note: REST APIs are good for modeling systems and data, but there are specific cases where there could be better alternatives—for example, streaming data. Newer mechanisms of communication, such as gRPC, JSON-RPC, and GraphQL, are emerging. However, typically the concepts mentioned in this course should be applicable for non-REST APIs as well.

Nuances of REST API security

If there is a layer of authentication prior to hitting the REST API, it is assumed that the REST API is secure. While authentication and authorization play a very important role in securing the REST APIs, there are several other security measures that need to be put in place. In this course, we’ll learn methods to better secure them.

What is CVSS?

Common Vulnerability Scoring Mechanism (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. The scores it gives vulnerabilities range from 0-10, 10 being the most severe.

This scoring is done based on several factors. For example, if the system can be exploited without the user performing any operation, it is a severe vulnerability. If user interaction is required for an attacker to exploit the system, this is also a high-numbered vulnerability