API Security: Red Teaming Exercises

The first step to establishing your API security program is to obtain visibility. The proliferation of APIs across a distributed infrastructure inevitably leads to API sprawl, and most organizations don’t know how many APIs they have or how they’re utilized. Developers often stand up new APIs or reuse existing ones, but much of this is out of sight of security. As a result, the attack surface created by APIs is significantly larger than most organizations realize.

Once you know what APIs you have and are familiar with their functionality, it’s time to think about protecting them. Protection falls under three categories that most security professionals are familiar with: red teaming, blue teaming, and purple teaming.

API Security Red Teaming

Red teaming is offensive security. This includes proactive efforts such as penetration testing and security testing in an attempt to breach your organization’s security and see how far one can get in an organization. Uncovering vulnerabilities is a primary focus for typical red-teamers. For the purposes of an API security program, red teaming efforts should focus on the following:

(Note: the following is not an exhaustive list of protection mechanisms, but key concepts that will give your program a solid start.)

Authentication and Authorization

Many of the most common API vulnerabilities are related to authentication and authorization flaws. Developers may, for example, loosely configure an API’s authorization checks based on assumptions about the clients interacting with it. This leaves application functions or API calls available to any attacker who steals the API keys or — worse — discovers that an API doesn’t require authentication keys. Even when developers configure APIs with strong authentication requirements, they may violate the principle of least privilege by granting API clients access to more data and application functions than necessary.

So, first and foremost, from a red teaming perspective, ensure that authentication and authorization mechanisms are working as intended and that only authorized users have access to API resources. Test for weaknesses in these mechanisms, such as weak passwords, insufficient validation of access tokens, and ensure that the people or machines authorized to access or pull the data from an API have a legitimate need to do so. The concept of “Zero Trust” comes into play here — don’t trust anyone or anything until you do proper authentication and authorization. Validate and verify.

Encryption

Another way to prevent unauthorized access to your data is via encryption, which creates secure communication between the user and source. SSL/TLS encryption is mainstream and should be used for both public and private APIs, especially those that are holding or transmitting sensitive data. Always use the strongest encryption methods to protect your APIs, such as TLS 1.3.

In addition to enabling encryption, it’s important to test your API’s encryption mechanisms to ensure that they’re working as intended, and that sensitive data transmitted via the API is actually protected. This can include tests for SSL/TLS encryption and key strength.

Rate Limiting and Throttling

Next, look at rate limiting and throttling. Rate limiting restricts the number of requests an API can process, regulating legitimate users while protecting against malicious attacks. Rate limiting is especially important for public-facing APIs to ensure that they are not leveraged in a distributed denial-of-service attack. Simple rate limits are available in many web servers and proxies.

Test APIs against these mechanisms to ensure that they’re able to prevent abuse and protect against, for example, DDoS attacks.

Stress-test your APIs and ask:

• Can my APIs handle high volumes of traffic?
• What is considered a “normal” amount of traffic for each API?
• Is an API being called upon excessively?

Over time, establish baselines for what constitutes normal traffic, including periods of peak traffic. This will enable you to more easily recognize when traffic has reached an uncharacteristically high volume and requires investigation and perhaps a response.