This week, we look at a survey of API security priorities in Asia Pacific and why canary testing became a hot topic following the Crowdstrike incident. We examine two cases of API vulnerabilities discovered in the field, and finally, we review the potential cost and implications of a data breach.
Survey: API security insights from APAC
A survey of 297 professionals across various industries in Asia-Pacific highlights the top concerns around API Security. Here are some of the insights that caught our attention in this report.
Internal APIs are the most commonly used APIs by organizations in the Asia Pacific region, but the biggest concern when it comes to API access control is the risk posed from external users.
This may indicate that API security is still viewed through a traditional lens of “perimeter security”, where a WAF or Gateway appliance deployed at the ingress/egress point centrally controls external user access to on-premise applications.
However, internal APIs present new security challenges. Without authorization and access control policies between internal APIs, a single breach at a benign entry point can quickly escalate into lateral attacks on more critical back-end systems.
So for organizations in the Asia Pacific region that primarily use internal APIs, access control policies for east-west traffic must also be a major concern. Protecting traffic between internal APIs requires security controls deployed closer to the API than the traditional edge perimeter.
Organizations in the Asia Pacific rank the OWASP API Top 10 vulnerabilities in different order than the standard list.
The top three vulnerabilities on the APAC list are:
- #1: Broken Authentication (API2:2023)
- #2: SSRF (API7:2023)
- #3: Security Misconfiguration (API8:2023).
Interestingly, priorities also differ across countries. For example, Malaysian organizations report that API3 (Broken Object Property Level Authorization) is the top risk, while New Zealand is more concerned about API10 (Unsafe Consumption of APIs).
So while OWASP API Top 10 list is a useful and relevant model, API security solutions must be both comprehensive and flexible to cover the different needs and priorities of organizations in the Asia Pacific region.
Data leakage is the top priority for API runtime protection
Previous incidents discussed in this newsletter, such as the Spoutible API incident, demonstrate why data leakage is such a critical concern, and why authorization checks should be performed on both API request and response messages.
API security often focuses primarily on threats from inbound requests. But even if you do all the work to harden and protect your APIs from outside attacks, those APIs can still leak sensitive data in very damaging ways, through development errors or inadequate authorization policies.
So this is a positive sign that organizations in the Asia Pacific region are recognizing and prioritizing risk on both sides of the API transaction, to address both inbound malicious attacks and outbound data leakage.
Article: Salutary lessons for management teams everywhere
Crowdstrike has been in the news for all the wrong reasons recently. On July 18, a software update containing a critical bug was distributed globally by Crowdstrike, causing millions of Windows machines worldwide to crash and fail to restart. Some media reports have called this incident the largest outage in the history of information technology.
As the fallout continues for affected customers and for Crowdstrike, there are important lessons to be learned for management teams who want to avoid testifying before the U.S. Congress about their internal software testing and deployment processes…or lack thereof.
As this article by The Register reports, in response to Crowdstrike’s promises to begin implementing practices like canary testing to prevent future disasters, angry investors were quick to point out that the company should have done canary testing in the first place. A class-action lawsuit filed by investors against Crowdstrike soon followed.
If you’re not familiar with the term, “canary testing” (sometimes called canary deployment) is the practice of releasing a new software update to a small subset of users initially, and then gradually releasing the update to all users. The benefit of this approach is that it allows users to test the latest version of the software, and in doing so catches critical flaws before the updates are released to a wider user base. If flaws are discovered and reported during the initial canary testing, damage is significantly limited to a small select subset of users.
This process of course also applies to pushing out updates to your API. So if your team hasn’t implemented this practice yet, don’t wait for the canaries to come home to roost.
Vulnerability: OWASP API vulnerabilities in Solar Platforms
As concerns about the impact of climate change continue to grow, we could expect to see increased investment and reliance on alternative energy sources around the world. Worryingly, the security of those new energy systems and their potential vulnerability to cyberattacks is being called into question by this report from a research team at BitDefender.
The report describes how critical API vulnerabilities were recently discovered in products from two of the world’s largest solar management platform manufacturers. The vulnerabilities discovered correspond to the top three vulnerabilities in the OWASP API Top 10 list:
- API1:2023 Broken Object Level Authorization
- API2:2023 Broken Authentication
- API3:2023 Broken Object Property Level Authorization
We should not be surprised to learn that APIs are being used in these safety-critical systems, as APIs facilitate interoperability between solar platforms and connected equipment from various manufacturers.
However, the security and reliability of critical systems should be paramount, and it is disconcerting that these platform APIs are vulnerable to authentication and authorization attacks that could potentially impact millions of people.
The Bitdefender team should be commended for ethically discovering and reporting the API vulnerabilities to both vendors. However, the incident raises serious questions about regulations, standards, and practices for developing API for solar power devices.
Other industries such as the Automotive industry have already established standards mandating cybersecurity and API protection for vehicle manufacturing. Similar standards are clearly needed to protect our critical energy infrastructure in the future.
Vulnerability: Siemens React app missing API authorization
A research team recently discovered a vulnerability in a React app from Siemens which allowed them to bypass the app’s client authentication and retrieve unauthorized data from the API.
According to the team’s report, the API failed to enforce authorization on the applications requests, trusting instead that the app had already authenticated and authorized the user on the client side before making the API requests. This is a critical error in API development.
A React single page application (SPA) is typically developed as a combination of a client-side UI component that renders a display in the user’s browser, and a server-side API that provides data to the client UI as needed…and hopefully as authorized.
It is important to note that data returned by an API to the client can be exposed, even if it is not displayed in the client UI. For example, an attacker can easily bypass the client and interact directly with the API. For this reason, SPAs should never perform client-side authentication or authorization. Instead, all data requests should be authorized by an API, and an API should only return necessary and authorized data to the client-side application.
This is a fairly common mistake made by app developers, and can expose an organization to unauthorized access to data. We recently reported on a similar case in the newsletter, where two curious students from Santa Cruz managed to hack into a national network of washing machines. API hygiene indeed!
To protect against similar vulnerabilities in your Angular or React applications, test APIs directly to ensure that a valid credential or access token is always required by the API before returning private data. Additionally, limit the data returned by the API to what is necessary and authorized for each client request, to avoid exposing excessive data to the client.
Report: Cost of data breaches rises to USD 4.88 million
A Ponemon Institute study of 604 organizations affected by data breaches between March 2023 and February 2024 found a 10% increase in the average cost of a data breach over the past year. The average cost to an organization is now USD 4.88 million.
One of the biggest factors that influences the cost of a breach is the time it takes to identify and contain the breach. We noted the following statistics from the study:
- The mean time to identify a breach is 194 days
- The mean time to contain an identified breach is 64 days
This suggests the greatest opportunity to reduce the overall cost of a data breach lies in early identification, and the report also indicates which actors typically identify a breach: the organization, the attacker, or an ethical third party.
It is therefore worth noting that it is in the best interest of organizations to facilitate a formal process and communication channel so that external researchers can disclose vulnerabilities in an ethical manner. This is not always the case, and some researchers have in the past expressed frustration when trying to disclose their findings to an organization.
Something as basic and relatively inexpensive as a dedicated contact address or secure channel that is easy for researchers to find and quick in response, could save an organization millions of dollars by leveraging the help from external parties to reduce the mean time to identify a data breach.
The study also found that stolen credentials were the most common attack vector in 2024, used by attackers in 16% of all data breaches. This is an important point for API teams, as an Imperva report from this year also found that 44% of all automated attacks aimed at compromising user credentials target APIs.
APIs therefore remain a prominent target for attackers and require reliable and effective API security to avoid the costs of data breaches.
Breach: Tencent incident highlights consequences of data leaks
A hacker has released the account information of more than 1.4 billion users, claiming that the data came from Chinese tech company Tencent. Researchers at Hackread.com believe the data may have come from a massive data breach discovered in January this year.
In this latest report, the research team lists the potential consequences that companies can face if customer data is stolen and exposed. This list can be a useful resource for a security professional looking to convince the management team to increase the security budget.
The list of negative consequences for an organization includes:
- privacy violations
- reputational damage
- financial impact
- regulatory scrutiny
- increased cybersecurity risks
- impact on users
Are there any other potential implications not mentioned here? You can email your ideas or suggestions to editor@42crunch.com
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
