Securing API endpoints from hostile usage is challenging. In many ways, API security is different than typical approaches to web security.
In traditional web security, the following are usually true.
There’s a “castle and moat” approach. The network has a well-protected perimeter. There are only a few ways through the perimeter, and these access points are heavily guarded. Once requestors are allowed through the perimeter, they’re assumed to be benign.
Incoming requests will adhere to well-defined protocols that are mostly static. Therefore, the WAF (Web Application Firewall) can be configured to enforce those protocols.
Clients will be using a web browser. Therefore, the WAF can verify the browser environment. If verification fails, then it’s probably safe to assume that the client is a bot using an emulator or headless browser.
Attacks can be detected by examining the requests. For example, the WAF can block attempts at XSS (cross-site scripting). Or, it can notice a large volume of incoming traffic from a single IP, and determine that it’s an attempted DDoS attack (Distributed Denial of Service).
How is API Security Different?
APIs present a very different situation than that described above.
The castle has lots of openings, and no moat. The days of only protecting ports 80 and 443 (HTTP and HTTPS) are over. Today, web applications can have numerous API endpoints. Different APIs can use different protocols. And APIs tend to expand over time, so even an individual API can become difficult to secure properly.
Incoming request formats can change frequently. In a DevOps environment, APIs can evolve rapidly. Most WAFs are not designed to accommodate this. Each time an API changes, a typical security solution requires manual tuning and reconfiguring—which not only consumes time and resources, it can be an error-prone process. Thus, security can be compromised.
Clients will probably not be using a web browser. Most service/microservice APIs are accessed by mobile/native applications, or by other services or software components. This means that a web security solution cannot use browser verification, because the client is not using a browser. Unfortunately, most solutions rely heavily on this technique to detect hostile bots. Therefore, they find it very difficult to exclude automated traffic from API endpoints.
Attacks are not necessarily detectable within the incoming requests. Many forms of API abuse are based on requests that seem legitimate. For an illustration of this, see this example of Application Abuse.
How Do Development Practices Affect API Security?
Modern development practices affect API security in a number of different ways.
Focus. When developers work with APIs, they focus on a set of services. They concentrate on the feature set that the services offer, how to expand it, and how to make it as robust as possible. But hackers think differently: they look for ways to use gateways for nefarious purposes.
Rising complexity. In today’s world, network connections are more numerous, and system design has become more complex. APIs often support thousands of possible connections. Meanwhile, programmers are under pressure to deliver new releases ASAP. Mistakes can be made, and often are. Important steps in the development and/or testing processes can be missed.
Broad attack surfaces. Another side effect of rising complexity is that it creates abundant opportunities for abuse that were unanticipated by the developers. It is easy for newly-created vulnerabilities to go unnoticed.
Rapid change. As mentioned previously, in DevOps and DevSecOps environments, APIs can evolve constantly. Again, security holes can be created.
Division of labor. A robust API backend is usually the work of a large team. When different developers are responsible for different pieces, it can be difficult to coordinate and enforce best practices for security.
Opposing goals. When publishing an API, developers and product managers want to expose as much functionality as possible. But tight security is easiest when exposing the least amount of functionality.
Structure. An important security practice is the “principle of least privilege.” Every user of a system should have the minimal amount of access and permissions necessary. This requires a granularity of the underlying system that APIs often are not designed to support, not to mention a complicated authentication system within the API itself.
Purpose. An API is designed to provide a defined feature-set to external users. Rarely if ever does an API endpoint include built-in security capabilities such as rate limiting, client authorization, client identification, automated traffic recognition, and so on.