Introduction

An API is designed to interact with other software and there are several approaches for exposing : [[RPC]], [[RMI]], [[REST]], [[GraphQL]]

Different API styles are suitable for different environments. We might use an efficient RPC framework for internal communication between microservices, while we expose external APIs with REST

API security lies at the intersection of several security disciplines : Information security, Network security and Application security.

Designing a secure API

There is no such thing as a perfectly secure system, and there isn’t even a single definition of “security”. When we are designing a secure API, we should consider several aspects :

• The assets that are to be protected
• Which security goals are important
• The environment in which the API is to operate, and the threats that exist in that environment
• The mechanisms that are available to achieve these goals

For most APIs, the assets will consist of information (such as customer names or other information), but we should also consider physical assets such as the physical servers or devices that your API is running on.

Security goals are used to define what security actually means for the protection of your assets. There are several standard security goals that apply to almost all systems. The most famous are the so-called CIA triad :

• Confidentiality : ensuring information can only be read by its intended audience
• Integrity : preventing unauthorized creation, modification or destruction of information
• Availability : ensuring that the legitimate users of an API can access it when they need to and are not prevented from doing so

A good definition of API security must also consider the environment and the potential threats. One popular threat modeling methodology is STRIDE.

Threats can be countered by applying security mechanisms that ensure that particular security goals are met. Most common security mechanisms are :

• encryption
• authentication
• access control
• audit logging
• rate limiting

![[security_mechanisms.png]] ![[security_mechanisms_2.png]]

Rate limiting

Rate limiting is generally put in place as a defensive measure for services. Shared services need to protect themselves from excessive use—whether intended or unintended—to maintain service availability.

Rate-limiting should be applied as early as possible.

• https://tyk.io/blog/api-management-101-rate-limiting/
• https://cloud.google.com/architecture/rate-limiting-strategies-techniques

Audit logging

Accountability relies on being able to determine who did what and when.

The simplest way to do this is to store every raw request in db or elsewhere. For more complex and/or robust systems, you should use a [[SIEM]] system.

Don’t forget privacy by removing confidential data.

Access control

We usually separate access control into two : authentication and authorization.

Authentication is about who the user is, while authorization is about what the user can do?

See [[API Authentication]]

See [[API Authorization]]

Attacks

• SQL injection

• [[CSRF attacks]]

• Session fixation attacks

#publish