Defending against Common Vulnerabilities

In this chapter, we take our first steps into learning how to defend APIs against common vulnerabilities in the design and development stage of the Software Development Lifecycle (SDLC). We have previously explored ways in which attackers can exploit weaknesses in API design and implementation and have reviewed past breaches for examples and fallout from insecure APIs; our focus now shifts to learning a defensive mindset to build secure APIs. This chapter will deal with each of the major classes of vulnerability types and, for each type, will provide best practices, common pitfalls, recommendations for tools and libraries, and code samples illustrating key defensive methods. If you are a developer, this is a key chapter in your learning journey, and by the end of this chapter, you will be well on your way to building secure APIs. For other readers, this chapter gives a solid understanding of key defensive techniques.

In Chapter 7, Attacking...

Technical requirements

For this chapter, you will need a development machine capable of the following:

• Running VS Code with various marketplace extensions
• Accessing the internet and a GitHub account to access the examples

This chapter does not contain any specific code samples but provides code snippets and, in particular, JWT samples. No specific tools are required other than access to common online tools available via a standard web browser.

The example code and various breaking changes to the instructions can be found in the Chapter 9 folder on the book’s GitHub repository here: https://github.com/PacktPublishing/Defending-APIs/tree/main/Chapter9

Authentication vulnerabilities

Authentication attacks are the most frequently encountered attack vectors in APIs, and fortunately, they are also one of the easiest to defend by following core best practices in handling JWT security, implementing OAuth2 securely, and hardening your passwords, tokens, and your reset process.

Handling JWTs securely

In Chapter 7, Token-Based Attacks, we looked at various attacks against JSON Web Tokens (JWTs), since JWTs are ubiquitous within modern API implementations. Fortunately, nearly all of these attacks can be eliminated entirely by the secure handling of JWTs in the code that generates and consumes them.

The first recommendation is to make sure you are using JWTs for their intended purpose (a portable way of exchanging information about identity and permissions) and not attempting to use them where they are ill suited, for example, as a session cookie. Using this anti-pattern means a user cannot be logged out until the JWT expires, and...

Authorization vulnerabilities

Now that we have covered how to secure your API authentication, we focus on its counterpart – authorization. We will cover patterns for protecting against object-level and function-level vulnerabilities and how to apply various authorization middleware to improve overall authorization robustness and extensibility.

Object-level vulnerabilities

In Chapter 3, Understanding Common API Vulnerabilities, we covered the root causes of broken object-level vulnerabilities in the API1:2019 – Broken object-level authorization section. As a reminder, this vulnerability originates when an API grants access to an object (typically data) not owned by the calling user or client.

Despite its prevalence and reputation as the most serious of API vulnerabilities, broken object-level authorization is paradoxically one of the easiest vulnerabilities to address as a defender. The rule is simple – always explicitly validate the access to an object...

Data vulnerabilities

Data vulnerabilities are one of the most significant weaknesses impacting API security, with nearly all breaches involving data leakage to some extent. For API defenders, the good news is that it is a vulnerability class that can be defended using some core principles and techniques.

Let us start our journey by understanding how data propagates through an API from the request, via the API layer, then the database layer, where it will be persisted to a database storage layer. A response follows the reverse flow: data is accessed from the database via the database layer, processed by the API layer, and returned to the user or client in the response.

This is summarized in the following simplified architecture diagram:

Figure 9.3 – Typical API data controller model

There are three data processing layers, each with its own data object:

• Data input object: This is the native input format data received in the API request...

Implementation vulnerabilities

In the final portion of this chapter, we will cover the remaining vulnerabilities without going into a deep level of detail. Many of these vulnerabilities are not specific to APIs but affect many software systems, and there is already a body of knowledge in the industry on how to address these issues. I have included a Further reading section at the end of this chapter, and as always, the reader is well advised to consult the OWASP project, which maintains excellent guides and resources on these topics.

Injection

Injection vulnerabilities have plagued software systems for over two decades already; fortunately, it is a vulnerability class that can be totally eliminated by implementing patterns for secure coding. Injection attacks occur when a system trusts user input without validating it, allowing an attacker to launch attacks against underlying components such as databases, operating systems, and filesystems. Typical examples include SQL injection...

Protecting against unrestricted resource consumption

The primary way to protect against the overuse of API resources is to implement rate limiting and throttling on your APIs. API rate limiting monitors the access to an API endpoint for a given client (usually based on IP address) and checks to see whether a predetermined allowed number of accesses has been made within a given window. If so, then the client will be rate-limited, typically with 429 Too Many Requests. The client will have the option to back off and retry the request or fail outright.

The server uses several different algorithms to detect the rate-limiting threshold, and some may be quite adaptive to only trigger in extreme cases of abuse. For example, the server can block many requests over a wide window or may only block on very high peak demands (or bursts) of access. The choice will depend on the perceived threats to the API, for example, denial-of-service attacks or mass data exfiltration.

Rate limiting can...

Defending against API business-level attacks

Finally, let us conclude this chapter by looking at the two business-level vulnerabilities included in the OWASP API Security Top 10 2023.

Unrestricted access to sensitive business flows

This vulnerability results when an attacker can abuse the standard flow of an API-based application to subvert the original business intent to their benefit. Typical examples include abuse of airline ticket booking systems, online event ticketing systems, or various online retailers.

The exact nature of the abuse will depend on the specifics of the industry and how their API design maps to their business flows. Unfortunately, this is one of the hardest vulnerabilities to defend against because, unlike many of the others covered already, there is no single point of fix. In fact, the APIs themselves may be flawless, but by being used in a nefarious fashion, they expose the business to risk.

Typically, risk minimization involves both the business...

Summary

This has been a key chapter in your journey in learning how to defend APIs from attacks. The key learning point is that while the attack vectors are vast and varied, there are well-established patterns for defending APIs against common vulnerabilities.

Firstly, we examined how to deal with common authentication vulnerabilities, focusing on best practices for handling JWTs securely, using OAuth2 securely, and securing your passwords, tokens, and reset process. Whilst the recommendations are extensive, developers will benefit from following these guidelines to avoid some of the most nefarious authentication vulnerabilities. Secondly, authorization of your APIs poses significant challenges, and in this chapter, we learned how to address both object-level and function-level vulnerabilities through the judicious usage of authorization middleware to bolster your defenses.

Thirdly, we dealt with the critical vulnerabilities associated with API data, namely excessive data exposure...

Further reading

These links provide further reading on handling JWTs:

• https://42crunch.com/7-ways-to-avoid-jwt-pitfalls/
• https://auth0.com/blog/a-look-at-the-latest-draft-for-jwt-bcp/
• https://curity.io/resources/learn/jwt-best-practices/
• https://redis.com/blog/json-web-tokens-jwt-are-dangerous-for-user-sessions/

These links provide further reading on implementing OAuth2:

• https://pragmaticwebsecurity.com/files/cheatsheets/oauth2securityfordevelopers.pdf
• https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics
• https://auth0.com/resources/ebooks/oauth-openid-connect-professional-guide/
• https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/
• https://curity.io/resources/learn/spa-best-practices/
• https://datatracker.ietf.org/doc/html/rfc6819

These links provide further reading on using authorization middleware:

• https://casbin.org/
• https://www...