API Security: How to take a layered approach to protect your data
With the popularization of rapid development and deployment pipelines such as DevOps and Agile, implementing security measures early in the development cycle is more important than ever. Modern APIs and libraries can shorten the time to market for applications. However, as we have seen with recent security and data breaches, they may also expose a substantial attack surface.
Finding universal one-size-fits-all methods for securing APIs has been one of the biggest challenges for software developers and IT leaders. Nevertheless, as you will see from this article, a layered approach to API security may be far more effective. You will learn what it is and how it can help organizations balance cost and efficacy.
11 courses, 8+ hours of training
Why better approaches to securing APIs are necessary
Many companies fail to provide ample API security. They may have real-time vulnerability scanning or penetration-testing tools, but they are not enough to protect APIs, which have an ever-increasing number of attack layers. APIs often contain critical business information, providing glaring opportunities for exploitation and cyber incidents.
Due to insufficient API security, various companies suffer data breaches and leaks. In many instances, bad actors opted to target business logic and access control vulnerabilities instead of using traditional routes such as SQL injections and cross-site scripting.
Thus, attacks have diversified and have also increased in frequency. Google’s 2020 State of API Economy Report found a staggering 172% increase in abusive API traffic. Insufficient cybersecurity can leave organizations at risk of violating regulations such as HIPAA and the GDPR, which may result in hefty fines and other penalties.
Providing comprehensive security for APIs can be quite complex, but it is crucial.
Most common API attacks
The number of layers an API has depends on its purpose and complexity. Modern cybercriminals often employ four common API attacks [DDoS, injection & data attacks, RBAC and ABAC attacks, and exploiting business logic flaws].
Each attack corresponds to one of the four most common software and API architecture layers. The attack types and the layers they correspond to are described below:
Distributed denial of service (DDOS)
Similar to phishing scams, distributed denial of service (DDOS) attacks are among the internet’s easiest and most widespread cyberattacks. Bad actors will try to interrupt a website, application, or API service by overloading it with requests or network traffic.
DDOS attacks can be partially mitigated by using rate-limiting features that manage the number of incoming requests on an API’s gateway. However, we have seen bad actors circumvent these security measures by sending less frequent but more resource-demanding requests. For instance, they may attempt to initiate an application query (such as a search) that returns a large data set. Mismanaged results from too many requests may overload the API’s services. This attack corresponds with the network and service delivery layer of the API.
Injection & data attacks
Injection and data attacks involve malicious programming code sent or “injected” by an attacker. The attacker attempts to modify the API’s configurations, source code or databases to steal data. This attack corresponds with the data layer.
Role-based access control (RBAC) & attribute-based access control (ABAC) attacks
When internal actors are given excessive amounts of privilege, it may lead to a surge of RBAC or ABAC rules that can be easily exploited if they are not tested thoroughly.
Privilege escalation vulnerabilities and unauthorized access to resources can be extremely hard to detect. These types of attacks correspond to what is known as the identity and access layer.
The exploitation of business logic flaws
Often applications may malfunction, not because of a coding error but a misunderstanding of the use case. Developers who may not fully understand the use case or business logic they are designing software for are at great risk of making business logic-based mistakes. Cybercriminals may exploit these errors to expose the organization’s data, damaging its reputation. This is one of the trickiest vulnerabilities to detect and prevent. It corresponds with the business and application layer.
Securing each API layer
Once you identify the attack categories that your APIs may be vulnerable to (and, in turn, their layers), you can begin to formulate practices and methods for securing them.
Securing the network & service layer
One of the simplest ways to defend your application from DDOS attacks is through pagination, in which results from queries are segmented and returned in more network-friendly chunks. For instance, an attacker may attempt to initiate a search that returns millions of queries. Pagination will limit the number of results returned at a time or the total number of results for each query. Pagination is written into the API’s code.
Another good strategy to help prevent DDoS attacks is API throttling, or limiting the amount of API requests that a user can make within a specified period of time.
Securing the data layer
You can prevent cross-site scripting and SQL injection attacks through input validation and prepared statements. In fact, the use of prepared statements is considered one of the most important coding practices for secure PHP. You must avoid concatenating any input data to SQL queries other than bound parameters.
Furthermore, you must validate all input data server-side. We’ve seen how a bad actor can easily bypass JavaScript validation performed on the client-side. They can simply disable the JavaScript on the web browser or use a web proxy. Thus, you must perform validation both on the client-side and the server-side.
HTML (input) entity encoding is another way to mitigate XSS vulnerabilities. User input data is encrypted before a response is sent to the web browser. Although we have seen many developers implement entity encoding for HTML, they tend to leave input data placed in scripts unprotected. This issue should be addressed as well.
Securing the identity & access layer
Continuous assessment of RBAC across every API, feature and role mapping is the best way to secure your API against attacks that use privilege escalation. This should be done during the API and application’s development process to detect any RBAC vulnerabilities as early as possible.
In addition, you should continuously monitor and test object and action attributes (API resources and methods) during the application development process. This is the best way to prevent ABAC attacks.
Securing the business and application layer
You can prevent business logic flaws by continuously auditing and testing your applications and APIs. In attempting to meet deadlines, developers often neglect basic practices such as data encapsulation and the principle of least privilege. In addition, developers must implement effective QA testing measures involving experienced business users.
11 courses, 8+ hours of training
Conclusion
N-tier layered architecture remains the most utilized software architecture design. This approach requires software to be written to emulate conventional IT organizational patterns. Most software (including APIs) follows a simple four-tier/layer pattern. Thus, we should consider securing it by using a similar approach to maximize security while keeping costs low.
Although cybercriminals are primarily interested in the database or data layer, they may use the other layers as entry routes. Software engineers and tech leads must ensure that each layer has sufficient coverage for their secure software development life cycle (SSDLC) strategy.
Sources
- The State of API Economy 2021 Report, Google
- What Is HIPAA Compliance? HIPAA Compliance Checklist & Guide 2022, Atlantic.net
- API layer, MuleSoft.com
- 10 Best Practices to Prevent DDoS Attacks, SecurityScorecard
- Phishing scams: Don’t get hooked, Wave
- Reputation Management: The Complete Guide to Managing Your Business’ Reputation Online, Weave
- Role Mapping Providers, Oracle