A Guide to Security Controls for Risk-Based API Protection

In the interconnected world of today, APIs (Application Programming Interface) are the invisible bridges that let applications talk to one another. But to those that with great power, there must also come great responsibility! They need to be able to secure these APIs in order to protect the privacy of their own data or user information from would-be attackers. In this post, we are going to navigate risk-based API security controls which are essential in helping you construct more solid and tamper-proof APIs.

1. Threat Modeling for Shift-Left Secure Design Practices

Just think of construction projects. It would perform well to find these structural flaws in the blueprint stage rather than after you build it, wouldn't that be even upstanding? Threat modeling is based on the same way of thinking The shift-left mentality, in action, is identifying and remediating security flaws at the earliest possible point — prior to deploying APIs.

Example

Consider an e-commerce API that processes user payments. Developers can threat model to help recognize potential threats like SQL Injection or Man In The Middle attacks and implement countermeasures that much sooner

2. API Discovery and Cataloging

Your APIs are like a library full of useful information. If you do not know what APIs are available to your developers or how the data those constructs handle? When it comes to API discovery and cataloging, this means having a complete list of all your APIs. That includes what they do, how you access them and the data exchanged with them.

Example

A table that contains every API, what we use it for, and the dataset that comes out of each one. This is not just used for security analysis but also helps in managing and governing the API.

3. API Gateway and Service Mesh Deployment

Just picture a castle gate, instead of guards defending it with their lives. An analogous role for the API gateway is as a single chokepoint through which all traffic must pass. Provides the necessary authentication, authorization, rate limiting, and throttling policies for your backend systems to restrict requests.

Service meshes extend one step further. They provide a virtual layer that stands between your Microservices and deals with the communication between them. They have fine-grained control over the enforcement of security policies like encryption or access control and offer an extra layer of protection.

Example

Leveraging API gateway such as Kong to enforce security policies on every incoming API request across the organization, allowing only authenticated requests to be further processed.

4. Continuous Monitoring and Layered Security Defenses

Be a good API security guard and view the live footage. You see, tools like SIEM (Security information and event management) are designed to track API infractions almost in real-time. Whatever looks suspicious or resembles an attack communicates itself as an abnormal activity alert right away (most of the time).

Example

Now think of a dashboard with API traffic patterns, if a sudden flood of requests gets sent from an unknown IP address it can trigger the need for further investigation.

5. Authentication and Authorization Controls

Think of a medieval castle in terms of multiple layers — the moat, drawbridge, and thick walls. This approach of layered security for APIs is based on the same principle. This means employing a number of security measures to form layers, through which an attack must go.

This could include:

• Authentication and authorization measures: Checking that the user is who they say are, and has been granted access to specify parameter controls in your API.
• Disallowed weak authentication schemes: It prohibits the usage of weak authentication mechanisms like basic schemes and favors robust protocols such as oAuth.
• Retiring deprecated/legacy flows: Discontinuing support for old API capabilities where any vulnerabilities are likely to be lurking.

Example

Using OAuth 2.0 for secure authentication and role-based access control (RBAC) to control user permissions.

6. Short-Lived Tokens: Reducing the Risk

It is equivalent to a temporary pass for someone coming to visit your castle not giving them the keys permanently. Short API token lifetimes provide a similar risk reduction of only allowing a session to be maintained for so long — that is, when an API token runs out there has been some limit on the potential rotation through existing geographic locations via this client ID/secret pair. 

Example

When your tokens expire in 10 minutes, you simply make it more difficult for an attacker to get a valid one and compress his window of opportunity.

7. Message Input Validation

API input validation does what a security guard would do in stopping someone with a suspicious package from entering the building: it ensures that only properly formed and authorized data makes its way into your system. By doing this an attacker is not able to inject a code like in the case of SQL injection where specific malicious input allows the hacker.

Example

Using data validation custom or open source libraries to check user inputs (formats and values).

8. Protect Secret Data through DLP (Data Loss Prevention)

Data loss prevention (DLP) methods help to protect a business's sensitive information traveling via APIs. This is where you would encrypt your data at rest, in transit, mask sensitive information, and prevent unauthorized Data Exfiltration.

Example

Masking or not returning sensitive data such as Password / Credit Card / PII in responses from APIs.

9. Never Hard Code API Secrets

For the same reason you wouldn't write your password down on a post-it note, saving API credentials right in code is a really bad security practice. Over time, hard-coded secrets can lead to a security risk or exposure. Managed API keys and tokens securely. 

Example

Store API keys with AWS Secrets Manager instead of hardcoding them in the application.

10. Confidentiality Measures

Confidentiality measures to keep data encrypted in transit and at rest.

Example

All communications between APIs will be HTTPS and encrypting sensitive data.

11. Per API Rate Limits

To prevent abuse and allow fair use by implementing rate limits on a per API endpoint basis.

Example

Limit user requests per minute to lock a down DOS attack.

12. APIs IP Allow and Deny Lists

Allows lists of IPs that can, or cannot access the API which improves security by not allowing everyone to have direct access.

Example

Restricting the access to one of your sensitive API endpoints to only the IP addresses from within their own network (ORG).

These design patterns are designed to work together as a layered security in-depth stack. Once you know your API risks, you can then decide what controls provide the most security benefit.