Lurking in the Shadows: Attack Trends Shine Light on API Threats

• A total of 29% of web attacks targeted APIs in the span of 12 months (January – December 2023), indicating that APIs are a focus area for cybercriminals.

• The range of attacks on APIs goes beyond the Open Web Application Security Project (OWASP) API Security Top 10, with adversaries predominantly using tried-and-true methods like Local File Inclusion (LFI), Structured Query Language injection (SQLi), and Cross-Site Scripting (XSS) to infiltrate their targets.  

• Business logic abuse is a critical concern because it is challenging to detect abnormal API activity without establishing a baseline for API behavior. Organizations without solutions to monitor anomalies in their API activity are at risk of runtime attacks like data scraping — a new data breach vector that uses authenticated APIs to slowly scrape data from within.

• APIs are at the heart of most of today’s digital transformations so understanding industry trends and relevant use cases (e.g., loyalty fraud, abuse, authorization, and carding attacks) is paramount. 

• Organizations need to think about compliance requirements and emerging legislation early to avoid the need to re-architect.

Organizations face myriad other API security challenges — in addition to the risks highlighted by the OWASP API Security Top 10 — such as common vulnerabilities that we categorized as posture problems and runtime problems.

1. Posture problems pertain to flaws in the enterprise’s API implementation. Alerts indicating posture problems help security teams identify and remediate high-priority vulnerabilities before they can be exploited by attackers. The most common posture problems include:

• Shadow endpoints
• Unauthenticated resource access
• Sensitive data in a URL
• Permissive CORS policy
• Excessive client errors

2. Runtime problems are active threats or behaviors that require an urgent response. While often critical in nature, these alerts are more nuanced than other types of security alerts since they take the form of API abuse (as opposed to more explicit infrastructure breach attempts). The most runtime problems include:

• Unauthenticated resource access attempt
• Abnormal JSON property
• Path parameter fuzzing attempt
• Impossible time travel
• Data scraping

It is also paramount to step back and look at three more general challenges that APIs face to ensure that your security program covers API abuse and exploitation.

1. Visibility: Do you have process and technical controls to ensure all APIs are protected by your program? This is a key issue as APIs are often part of the transformation or embedded in new products, so many do not have the same level of directions, protections, and validations of a traditional web presence. 

2. Vulnerabilities: Are your APIs following best practices for development? Are you avoiding OWASP's most common poor coding issues? Furthermore, are you tracking and checking for vulnerabilities?  

3. Business logic abuse: Do you have a baseline of expected traffic? Have you established what constitutes suspicious activities?

The answers to these questions form the basis of what your team should understand. The overall goals should be to have the visibility and ability to conduct investigations and to have processes established to rapidly mitigate threats. This is true for both customer-facing and internal APIs. The full SOTI report includes some illustrative industry-specific case studies of threat methodologies.

After you address the quality of the API programming, you must then make sure all your APIs are protected by your security program. The old saying ”You can’t protect what you don’t know about” has never been truer than in this scenario. Here are some criteria for your management goals:

• Discovery — Visibility into the inventory of APIs inside your organization
• Risk audit — Visibility into the risk posture of each discovered API
• Behavioral detection — Visibility into normal use versus abnormal abuse to see active threats on each API
• Investigations and threat hunting — Visibility into threats lurking inside your API estate found by expert human threat hunters

You can access those benefits with these five steps: 

1. Shine a light on the shadows

2. Get organized

3. Harden your API posture

4. Sharpen threat detection and response

5. Develop a stronger offense

Do not forget about compliance as you think about your security program. Although there are not yet many API laws/regulations today, there are a number of best practices (like the OWASP guidance on coding practices) and guidelines (like the ones from the American National Standards Institute) that you should take advantage of to ensure you are doing the right thing to protect your customers.

Current regulations like the European Union’s Global Data Protection Regulation (GDPR) include APIs, and new standards like the Payment Card Industry Data Security Standard (PCI DSS) v4.0 also specifically call out APIs and the importance of securing them.

As you strive to have all APIs protected by your security program, you need to evaluate your discovery, investigation, and mitigation capabilities. Next, your red teams should be testing the security posture for authentication and exposed data, as well as runtime issues like JSON properties and scraping.

These validation tests should be built as purple team exercises to ensure that you have current processes to mitigate the impacts. The use cases reviewed (like loyalty fraud and carding attack etc.) in the SOTI report are great templates to use for your test plans.