Defending Against API Abuse
Securing the Backbone of Modern Web Applications
Authors: Dennis Labossiere, Ruchir Arya, Weston Cole, Jackie Mak
In today's digital landscape, Application Programming Interfaces (APIs) are critical for enabling various web applications to communicate and share data seamlessly, but they have also become significant targets for cyber-attacks. Understanding API abuse and recognizing its threat is crucial for businesses. Attackers often exploit APIs through methods such as Distributed Denial of Service (DDoS), data theft, account takeover, and exploiting poor authentication, weak encryption, insecure endpoints, and insufficient rate limiting. The impact of such abuse can be severe, leading to financial losses, data breaches, and damaged reputations. Detection involves monitoring for statistical anomalies in API traffic, and KPMG LLP's approach includes establishing baselines to identify deviations indicative of attacks. Preparation and response strategies include thorough documentation, security testing, multi-factor authentication, and leveraging technologies like Web Application Firewalls (WAF) and API gateways. Staying informed about emerging threats and adopting practices such as Zero Trust architectures can help organizations defend against evolving API security threats.
Introduction and background
An Application Programming Interface (API) is a set of rules, protocols, and tools that allow different software to communicate with one another. An API is essential for enabling software systems to communicate and share data seamlessly. APIs use a request-response model where a client sends a request to an API, which processes it and returns a response. They enable web applications to interact and share functionalities, such as social media integration, payment processing, and data analytics.
APIs have become targets for cyber-attacks due to their vital role in interconnectivity. In recent years, the KPMG Cybersecurity and Technology Risk team have handled several incidents of API abuse by external attackers. These attacks targeted APIs in both web and mobile applications. A notable pattern observed was the extensive preparation by attackers, who spent significant time discovering and testing APIs. This preliminary testing likely helped attackers refine their methods, enabling the automation and orchestration of their attacks. Understanding and recognizing the threat of API abuse is crucial for businesses and developers.
Types of API abuse
With the interconnectivity of APIs it was only a matter of time before attackers began abusing their functionality. Below are several examples of weaknesses that attackers may exploit.
- Poor Authentication and Authorization – Weak or absent security protocols that allow attackers to bypass authentication and gain improper access levels.
- Lack of Encryption – Unencrypted data traveling between clients and servers is susceptible to interception. Encryption ensures that data remains confidential and tamper-proof during transmission.
- Insecure Endpoints – Exploiting poorly secured internal APIs through scanning tools to find and attack vulnerable endpoints.
- Insufficient Rate Limiting – Overwhelming APIs with excessive requests due to a lack of proper rate limiting, which controls the number of requests from a client within a certain period.
API abuse can take various forms, each with its unique methods and objectives. Below are examples of common attack vectors:
- Distributed Denial of Service (DDoS) Attacks – Overloading an API endpoint with excessive requests using botnets to disrupt the service, causing slowdowns or crashes.
- Data Theft – Exploiting vulnerabilities to gain unauthorized access to sensitive data, resulting in breaches involving personal, financial, or proprietary information.
- Account Takeover – Using stolen credentials to hijack accounts, exploiting weak authentication to gain unauthorized access, leading to identity theft and financial fraud.
How can you prepare for and respond to API abuse?
Sun Tzu famously wrote “if you know your enemy and know yourself, you need not fear the result of a hundred battles…”. Preparation begins with understanding how an attacker may target and abuse your APIs. Start by identifying your own APIs and understanding the baseline activity. Another effective solution is to enable multi-factor authentication (MFA). In enterprise environments, enabling MFA is not always easy to implement. There are downstream repercussions to consider. While 100% prevention may not be achievable, here are a few methods to assist with preventing API abuse.
- Document all API calls and their purpose thoroughly.
- Implement a web application firewall (WAF) to help with reconnaissance and rate limiting.
- Integrate static and dynamic application security testing (SAST/DAST) with continuous integration and continuous delivery (CI/CD) pipelines whenever code is changed.
- Perform manual penetration tests each time substantial changes are made to an API (e.g., new endpoints added, new logic added, changes to request or response parameters, etc.).
- Follow OWASP Top 10 for API1 and Mobile2 applications.
When responding to an incident involving API abuse, it is important to know what is being logged (e.g., Request and Response, true source IP, etc.), where the data is being logged (e.g., SIEM, data lake, etc.), and that the logs are fully and properly parsed. Leveraging a baseline makes it easier to build logic to detect the anomalies. For the more sophisticated attackers, additional steps and detection logic may be needed. These include frequency analysis, time differences, when the activity is occurring (working day vs. nighttime), and hunting for the techniques related to the type of attack (e.g., DDoS, account takeover, etc.).
API abuse remediation is dependent on the type of attack observed and the findings from the investigation. That said, below are a couple example remediation steps that should be considered when recovering from an incident involving API abuse.
- Expire authentication tokens such as JSON Web Tokens (JWTs) leveraged by external attackers.
- Revoke API tokens for compromised accounts / sessions tied to malicious activity.
Leading practices for securing APIs
1
2
3
4
5
As APIs continue to evolve, so do the tactics of attackers. Emerging trends in API security include the use of artificial intelligence (AI) and machine learning (ML) to detect and respond to threats in real-time.
Detecting API abuse
Identifying statistical anomalies and deviations within a Security Information and Event Management (SIEM) system or a security data lake (SDL) are effective techniques for threat hunting. It is important to note that having an established baseline of normal activity is crucial to spot these outliers related to an attacker.
One example of a statistical anomaly would be an unusually high spike in traffic for a particular API call. Similarly, an illustration of a standard deviation might involve detecting irregular patterns in API traffic over a given timeframe such as a 30, 60, or 90-day period . Another example of API abuse would involve unauthorized access to an API endpoint from countries where services are restricted. SIEMs, data lakes, or log analysis tools can reveal these unauthorized interactions originating from locations that do not align with the intended service use.
In general, implementing tools and systems to monitor API traffic can help detect anomalies and abuse. Machine learning-based solutions can also assist with identifying suspicious patterns and flag potential threats. However, there is no one-size-fits-all approach but there are factors to look for. These findings highlight the evolving tactics of external attackers and the importance of robust monitoring and defensive measures to safeguard API endpoints from exploitation and abuse.
From our analysis
Over the last several years, KPMG has assisted its clients with investigating abused APIs. When we assist our clients, it is important for us to establish a baseline of activity given the timeframe of the incident to which we are responding. We would start by looking at the specific events and build out the known knowns (e.g., specific APIs, remote IP address, etc.). To look for the unknowns, we build patterns from what is known and use frequency and statistical analysis for this. For example, we could calculate the time difference of the first and last observed activity from a suspicious IP address, total activity count, success and failure counts, and the success and failure rates.
The above methodology proved valuable on a data theft investigation. The result of our methodology was visualized as a data table using our client’s SIEM. With that data table, KPMG determined which IP addresses were most likely to be attacker-related and which were most likely to be normal/benign traffic. The attacker’s success rate was less than 5% whereas normal traffic had a greater than 85% success rate. Similarly, the suspicious IP addresses were only seen for a few hours whereas other IP addresses were observed for a few days or longer. When looking at a larger pool of data (180 days vs 30 days), KPMG observed periods of activity which pre-dated known attacker activity. These statistical anomalies deviated from known attacker activity and could have been the attacker performing their reconnaissance and initial testing.
For a separate investigation which was fraud-focused, the frequency and standard deviation was not noticeable nor were there noticeable statistical anomalies. The reason was this attacker had extensive knowledge of how our client’s APIs functioned. Instead of relying on statistical and frequency analysis, KPMG focused on the requests and responses. By doing so, a new pattern emerged which was then used to make a list of suspicious IP addresses. Using those IP addresses, we were able to make a list of impacted user accounts. After continually pivoting on IP addresses to find accounts and using accounts to find more IP addresses, each account and IP address was reviewed for anomalies, deviations, and patterns of fraud and/or abuse. With a finalized list of IP addresses and impacted accounts, we were able to uncover how the attacker was exploiting the API, the breadth of the attack, and how many accounts were impacted.
Conclusion
API abuse is a significant and growing threat to web applications. By understanding the types of abuse, recognizing common vulnerabilities, and implementing robust security measures, organizations can protect their APIs from cyber-attacks. Taking a proactive approach to API security is essential to maintain trust and safeguard sensitive data in an increasingly connected world.
How can KPMG help?
KPMG has experience helping organizations proactively manage the risks associated with, as well as responding to and recovering from API abuse incidents. From a preventative perspective, KPMG has deep experience with assessing and maturing cyber programs from a Governance, Risk and Compliance (GRC), cybersecurity and technology risk management standpoint, digital forensic and incident response, cyber defense, and managed services including application testing, penetration testing, and vulnerability assessments.
KPMG has conducted digital forensic investigations related to API abuse cases to help companies and their outside counsel determine the scope of the incident, what, if any data was removed, and prepare reports for customers or testimony.
1OWASP, “OWASP API Security Top 10”, (October 24, 2024).
2OWASP, “Mobile Top 10”, (October 24, 2024).
Explore more
Insight
Developing Effective Incident Response Strategies for Source Code Security
Discover the best practices for organizations to follow when their source code repositories are compromised.
Insight
Risk insights
Explore the latest webcasts and insights
Subscribe to Risk and Cyber Insights
The latest news and updates on how organizations can manage risk in today's environment.
Meet our Team
