API Design Security - I

API security fundamentals

With API usage growing exponentially, API exploitation has become a key attack vectorAttack vectors are the means through which a malicious user gains access to an entity. for malicious actors. An API doesn't function in isolation; it communicates with other applications (e.g., a Google API integrating with Facebook for sign-in). An insecure API, therefore, exposes not only its own data but also the sensitive data of every connected application. API security combines client-side and server-side application security, data security (at rest and in transit), and network security:

Consider an API like Spotify using Google for authentication: What protocols ensure sign-in credentials aren't intercepted? What information should be shared between applications to authenticate a user? Answering these questions requires understanding authentication, authorization, encryption, and access control. As digital attack surfacesAttack surfaces are the summation of all the entry points through which a malicious actor gains access to an entity. multiply, the primary attack methods include:

• Distributed denial of service: Multiple machines overload a target with requests, typically via a botnetA botnet is a group of exploited machines altered by malware. Such machines combine to create a network of bots to work on an attacker's agenda., disrupting normal operations.

• Insufficient authentication: Inadequately authenticated clients allow bogus or malicious calls that compromise access control.

• Injection: Malicious code entered into the system (commonly via cross-site scripting or SQL injection) endangers data and access control.

• Exposed data in API calls: Attackers intercept transmissions and impersonate a party (a person-in-the-middle attack), gaining unauthorized data access.

The diagram below illustrates where these attacks may originate:

No API is perfectly secure; APIs must be scalable enough to incorporate new security mechanisms over time.

The process of API security

Security is most cost-effective when considered at the inception of API design rather than retrofitted later. The key aspects of designing a secure API are illustrated below:

Assets

Assets are the sensitive data and entities that require protection: physical devices (application servers, caching servers, databases) and digital entities (stored data). Failure to protect them can lead to reputational and financial damage, which motivates defining clear security goals.

Security goals

The CIA triad is the foundational security model that establishes the groundwork for design principles and implementations.

The three factors are:

• Confidentiality: Ensures that only authenticated users access relevant information, enforcing secrecy and privacy.

• Integrity: Guarantees that information is accurate, reliable, and unaltered, whether from intentional modification or transmission corruption.

• Availability: Ensures that validated users have consistent access to resources through continuously functioning servers, machines, and applications.

Note: Although the CIA principles are the most widely used, other goals, such as accountability and nonrepudiation, can be helpful in other contexts.

Threat modeling

Defining the threats that an API faces in its operating environment is imperative. Public-facing APIs inherently provide attack surfaces, and these surfaces grow as API usage becomes more common. The set of threats relevant to an API constitutes its threat model, which can be classified using the STRIDE acronym, as expanded in the table below:

The threat modeling process:

1. Create a system diagram that highlights primary entities (clients and endpoints) and identify the trust boundariesA trust boundary is defined as the area in which all encompassed entities trust each other. for each component.

2. Identify information flow between entities, modeled as directed arrows.

3. For each trust boundary, map potential threats to security goals using the STRIDE model.

4. Select mechanisms to combat identified threats and record them for tracking throughout the development life cycle.

An example threat modeling diagram:

Note: The API and database have separate trust boundaries to prevent a compromised API from accessing sensitive database information.

The nature of the API dictates the security emphasis: an API that handles sensitive user data demands stricter measures than one that serves public data. Threat modeling uncovers system gaps and helps you direct defenses toward ...