Today, DDoS attacks stand out as the most widespread cyber threat, extending their impact to APIs.
When successfully executed, these attacks can cripple a system, presenting a more severe consequence than DDoS incidents targeting web applications.
The increased risk amplifies the potential for reputational damage to the company associated with the affected APIs.
How Does DDoS Affect Your APIs?
A DDoS attack on an API involves overwhelming the targeted API with a flood of traffic from multiple sources, disrupting its normal functioning and causing it to become unavailable to legitimate users.
This attack can be particularly damaging as APIs play a crucial role in enabling communication between different software applications, and disruption can impact the overall functionality of interconnected systems.
The impact of DDoS attacks is particularly severe for businesses and organizations that depend on their APIs to deliver essential services to customers. These attacks, employing methods such as UDP floods, SYN floods, HTTP floods, and others, pose a significant threat.
Typically orchestrated through botnets—networks of compromised devices under the control of a single attacker—DDoS attacks can cripple a target’s functionality.
DDoS attacks on APIs focus on the server and each part of your API service. But how do attackers manage to exploit DDoS attacks on APIs?
This Webinar on API attack simulation shows an example of a DDoS attack on APIs and how WAAP can protect the API endpoints.
Several factors can make APIs vulnerable to DDoS attacks:
Absence or insufficient Rate-Limiting: If an API lacks robust rate-limiting mechanisms, attackers can exploit this weakness by sending a massive volume of requests in a short period, overwhelming the system’s capacity to handle them.
Inadequate Authentication and Authorization: Weak or compromised authentication measures can allow malicious actors to gain unauthorized access to an API. Once inside, they may misuse the API by flooding it with requests, leading to a DDoS scenario.
Insufficient Monitoring and Anomaly Detection: Ineffective monitoring and anomaly detection systems can make identifying abnormal traffic patterns associated with a DDoS attack challenging. Prompt detection is crucial for implementing mitigation measures.
Scalability Issues: APIs that cannot scale dynamically in response to increased traffic may become targets for DDoS attacks. A sudden surge in requests can overload the system if it cannot scale its resources efficiently.
How Do WAAP Solutions Protect Against DDoS Attacks on API?
Web Application and API Protection (WAAP) platform offers in-line blocking capabilities for all layer seven traffic, comprehensively securing web applications and APIs.
To guarantee robust security, WAFs incorporated into WAAP solutions provide immediate defense by filtering, monitoring, detecting, and automatically blocking malicious traffic, thereby preventing its access to the server.
Active monitoring of traffic on an API endpoint enables the identification of abnormal traffic patterns commonly linked to DDoS attacks. Instances of sudden spikes in traffic volume serve as red flags for potential attacks, and a proficient monitoring system can promptly detect and address such increases.
In addition, WAAP enforces rate limits by assessing the number of requests from an IP address. API rate limiting is critical in mitigating DDoS damage and reducing calls, data volume, and types. Setting limits aligned with API capacity and user needs enhances security and improves the user experience.
To avoid impacting genuine users, find solutions that use behavioral analysis technologies to establish a baseline for rate limiting.
AppTrana WAAP’s DDoS mitigation employs adaptive behavioral analysis for comprehensive defense, detecting and mitigating various DDoS attacks with a layered approach. It distinguishes between “flash crowds” and real DDoS attacks, using real-time behavioral analysis for precise mitigation. This enhances accuracy compared to static rate limit-based systems.
APIs power the digital world—our phones, smartwatches, banking systems and shopping sites all rely on APIs to communicate. They can help ecommerce sites accept payments, enable healthcare systems to securely share patient data, and even give taxis and public transportation access to real-time traffic data.
Nearly every business today now uses them to build and provide better sites, apps and services to consumers. However, if unmanaged or unsecured, APIs present a goldmine for threat actors to exfiltrate potentially sensitive information.
“APIs are central to how applications and websites work, which makes them a rich, and relatively new, target for hackers,” said Matthew Prince, CEO at Cloudflare. “It’s vital that companies identify and protect all their APIs to prevent data breaches and secure their businesses.”
APIs popularity boosts attack volume
The seamless integrations that APIs allow for have driven organizations across industries to increasingly leverage them – some more quickly than others. The IoT, rail, bus and taxi, legal services, multimedia and games, and logistics and supply chain industries saw the highest share of API traffic in 2023.
APIs dominate dynamic Internet traffic around the globe (57%), with each region that Cloudflare protects seeing an increase in usage over the past year. However, the top regions that explosively adopted APIs and witnessed the highest traffic share in 2023 were Africa and Asia.
As with any popular business critical function that houses sensitive data, threat actors attempt to exploit any means necessary to gain access. The rise in popularity of APIs has also caused a rise in attack volume, with HTTP Anomaly, Injection attacks and file inclusion being the top three most commonly used attack types mitigated by Cloudflare.
Shadow APIs provide a defenseless path for threat actors
Organizations struggle to protect what they cannot see. Nearly 31% more API REST endpoints (when an API connects with the software program) were discovered through machine learning versus customer-provided identifiers – e.g., organizations lack a full inventory of their APIs.
Regardless if an organization has full visibility of all their APIs, DDoS mitigation solutions can help block potential threats. 33% of all mitigations applied to API threats were blocked by DDoS protections already in place.
“APIs are powerful tools for developers to create full-featured, complex applications to serve their customers, partners, and employees, but each API is a potential attack surface that needs to be secured,” said Melinda Marks, Practice Director, Cybersecurity, for Enterprise Strategy Group. “As this new report shows, organizations need more effective ways to address API security, including better visibility of APIs, ways to ensure secure authentication and authorization between connections, and better ways to protect their applications from attacks.”
The OWASP Foundation’s Top Ten lists have consistently aided defenders in directing their attention towards particular technologies, and the OWASP API (Application Programming Interface) Security Top 10 2023 is no different. Originally formulated five years ago and recently revised, its goal is to tackle evolving attack techniques.
However, the OWASP API Security Project leaders had their work cut out when deciding how to group and prioritize the threats. The list is put together based upon industry input and must reflect compliance concerns, so it was never going to completely satisfy all people. The question is, does it go far enough to be of value to those in the thick of it when it comes to API development and defense?
What has changed and what has stayed the same?
By comparing the old and the new list, we can see that the top two threats – API1 Broken Object Level Authorization (BOLA) and API2 Broken User Authentication – have remained unchanged. API1 denotes the manipulation of the identification of an object that is sent within a request to the API while API2 marks the abuse of authentication mechanisms through attacks such as credential stuffing, including forgotten/rest password functions. They provide the quickest wins for attackers, and it’s easy to see why these continue to the top the list.
API3 replaced Excessive Data Exposure with Broken Object Property Level Authorization. Does this mean we have solved the problem of sensitive data exposure? Alas, no, it continues to be a huge problem. What this change signifies is the next stage an attacker would take when exploiting sensitive data exposure, i.e., break through the property level authorization. So why has the Project decided to make the change? Probably for the sake of clarity, because sensitive data exposure is an issue that spans the rest of the list. But some, including myself, would argue that this isn’t the right way to present the issue, because it declasses what is a very serious issue.
Similarly, API6 was Mass Assignment in 2019 and is now Unrestricted Access to Sensitive Business Flows. Are they different? Not really. Both are talking about taking advantage of objects and their properties within the application flow, with the examples listed on the project page referring to a ride share app where functionality is exploited in the backend. There is, however, something subtle about the naming that makes the 2023 version seem like something that needs to be fixed, rather than being nebulous and confusing, so in that respect it is an improvement.
Bring bots into the mix
API6 also plays to how an API that isn’t functioning properly can swiftly end up with attack automation being utilized against it in the form of bot attacks. This is important because there’s always been an artificial distinction made between API and bot attacks, with the security sector offering different solutions for each when the reality is that automated attacks can and are launched against APIs. So, it no longer makes sense to monitor for API attacks and bot attacks separately: bot mitigation has to become part of API security. This is apparent in our recent report, which revealed that automated attacks dwarfed other TTPs in the analysis of traffic during the last quarter of 2022.
Overall, the new list largely redefines many of the previous tactics, techniques and procedures (TTPs) in a bid to be more inclusive. API4, for instance, has moved from Lack of Resources and Rate Limiting to become Unrestricted Resource Consumption, reflecting the fact that rate limiting extends beyond the issue of network capacity. Other resources that can be abused if limits are not set include CPU, memory and storage, for example, but just as importantly, service providers can find service resources maxed out by API requests. They may provide emails, texts or phone calls and a repeat API request can see that service provider rack up huge service costs.
However, there are some changes in the order and new concepts in there towards the end. API7 Security Misconfiguration drops a place to API8 as there has been progress made in this area.
API7 is now Server Side Request Forgery (SSRF). APIs are a prime target for SSRF attacks because they routinely channel outbound traffic from an application. Developers often access external resources, such as web hooks, file fetching from URLs or custom SSO and URL previews – states the Project – or cloud or container providers expose management and control channels to compromise via HTTP. And the old API8, Injection attacks? That’s no longer a separately categorized threat again because it’s typically adopted in many of the other attack types.
Significant changes
API9 sees another subtle but important change in the wording: from Improper Assets Management to Improper Inventory Management. This reflects the heightened number of shadow APIs that are out there which once deployed are no longer monitored and effectively fall off the security team’s radar. Unmanaged, unknown and unprotected, these APIs are then sitting ducks for attackers who now actively search for them. In fact, we found that 45 billion search attempts were made for shadow APIs during the second half of 2022, compared to five billion during the first six months. A runtime API inventory that continuously monitors production APIs is therefore vital to ensure all APIs that go live are protected yet it’s one of the key failings in organisations today.
Finally, API10 has changed from Insufficient Logging and Monitoring, now largely covered by API9, to Unsafe Consumption of APIs. This reflects the extension we’ve seen of the API software chain, with APIs now often being integrated with other APIs. The problem that has arisen is that developers tend to inherently trust interactions with these external APIs, particularly from well-known companies, even though they may be flawed and/or be leaking data.
Clearly a great deal of thought has gone into adjusting the OWASP API Top Ten to more accurately address the TTPs that attackers are now using. The result sees both minor and some major changes to the list all of which are justified. Indeed, it’s not the descriptors but the list itself that is problematic. It’s an arbitrary concept that’s designed to attract attention to and heighten the profile of API security but does it do anything to further how we defend against these attacks?
How it holds up under an attack scenario
If we use breach analysis, we can compare a typical breach to the categories in the list to see how the concept stacks up. Many breaches start out with an API that the victim organization was unaware they had ( API9 in the 2023 list). This API is then found to return some kind of data about a user that isn’t the attacker (API1). Now the attacker is going to create attack automation using a bot to try to exploit this as quickly and as completely as possible (API6), completing the attack chain and giving the attacker access to data hidden in the victim organization’s systems.
It’s evident that such an attack would cross at least three of the attack categories so prioritizing them becomes immaterial. Indeed, such trinity attacks are gaining ground, with 100 million detected during the first half of 2022.
What’s more, as well as seeing attackers pivot during an attack and utilize known TTPs, we are also seeing them come up with unique TTPs to attempt to subvert the API. These grew more than fivefold between June and November (from 2,000 to 11,000). Most of those attacks were geared towards achieving account takeover (ATO), scraping to perform reconnaissance or to exfiltrate data, and hunting for business logic flaws within the API to commit fraud.
Keeping up with such diverse attacks requires the security team to focus not just on its defense but methods of detection and mitigation. Whether it is knowing where APIs are, testing them for flaws or stopping bots attacking unknown flows, API security needs to become more comprehensive, tracking and protecting the API throughout its entire lifecycle.
A sound summary of TTPs
The new OWASP API Top 10 may not be perfect, but it does cover the bases and provides a great starting point from which to address the topic. It now recognizes that some attack methods such as sensitive data and exposure and injection attacks span multiple TTPs and so do not require a separate category. It also amplifies the need for bot mitigation as part of API security, and the complex nature of API ecosystems that are seeing them integrated with one another, for instance.
But its structure is not conducive to showing how these attacks are being used in the wild. It still compartmentalizes these attacks when threat actors are becoming much more versatile and combining them.
Realistically, the only way of keeping pace with this rapidly evolving threat landscape is to monitor and manage those APIs. Creating a runtime inventory, conducting API threat surface assessments, carrying out specification anomaly detection and putting in place real-time automated bot detection and mitigation are all now essential to protect the API footprint of the business.
A recent report reveals that the number of attacks on financial service APIs and web applications worldwide increased by 257%.
There are more APIs in use than ever, and the average FinTech company takes advantage of hundreds if not thousands of connections in their daily operations.
APIs have become a critical component of fintech but also open new vulnerabilities. 48% of financial service company states that API security remains the top concern of their API utilization.
So, what are the top FinTech API security challenges?
Impacts Of API Attacks on Fintech
API attacks on fintech companies can severely affect the financial industry and the customers who rely on these services. These attacks are becoming increasingly frequent as fintech companies grow in popularity and usage.
API attacks can have serious consequences, including financial loss and damage to a company’s reputation. These attacks can steal sensitive information like login credentials or financial data. This data can be used for identity theft, financial fraud, and other criminal activities, causing significant financial losses for the affected customers.
They can also be used to disrupt services or conduct fraudulent transactions. Additionally, service disruptions can lead to lost business, damage to reputation, and loss of customer trust.
API attacks can also have a ripple effect throughout the financial industry. If a major fintech company is compromised, it can cause mistrust and uncertainty among other financial institutions. This can lead to increased scrutiny and regulations for the entire industry.
Fintech companies must take proactive measures to secure their APIs and protect their customers’ data. This includes implementing robust authentication and authorization mechanisms, encryption for sensitive data, and regularly testing and updating security measures.
Additionally, having an incident response plan to address and mitigate potential breaches quickly is crucial in preserving customer trust and minimizing damage to the company’s reputation.
OWASP Top 10 API Security Risks
OWASP API Top 10 isn’t necessarily FinTech-specific. But with API usage exploding in every industry, it’s worth taking some time to understand the risks they’ve identified. After all, many modern companies would not exist without APIs.
Broken object-level authorization
Broken user authentication
Excessive data exposure
Lack of resources to rate limiting
Broken function-level authorization
Mass assignment
Security misconfiguration
Injection
Improper assets management
Insufficient logging and monitoring
What are the Challenges of Protecting APIs?
Explosive increase in API utilization
There has been a significant increase in the use of APIs in fintech in recent years. APIs allow fintech companies to easily integrate with other systems and services, such as banking platforms, payment processors, and data providers. This enables fintech companies to build new products and services quickly and easily and offer their customers a more comprehensive range of features.
As many APIs are integrated into third-party systems, it can be challenging to monitor for potential vulnerabilities.
Connections Create New Vulnerabilities & Risks
Most applications are made up of multiple services connected through APIs. This interconnectivity can inadvertently create new risks and vulnerabilities.
As interconnected services increase, the complexity of securing API connections also increases. Each connection represents a potential vulnerability that malicious actors could exploit. Additionally, as more services are connected, the attack surface for potential vulnerabilities also increases.
Data Exposure
FinTech companies handle sensitive financial information, making them prime targets for cyber attacks.
Tracking and monitoring for potential security threats can make it more difficult as more data is exposed through APIs. It can be difficult to track exactly,
What needs to be protected and how?
Where are APIs exposing data?
Is the exposure necessary?
The larger the amount of data and the more diverse the sources, the harder it can be to identify and respond to security incidents.
Furthermore, the increased use of cloud and third-party services can complicate tracking, as it can be challenging to determine where data is being stored and how it is being used.
Data exposure can also be a moving target based on API updates. For maximum security, you must always remain mindful of changes.
Rapid Development
An API in FinTech is perfect for rapid innovation and development. New updates, features, and functionality can be rolled out quickly and smoothly.
APIs are constantly changing. And because of that, app developers need to roll out multiple updates yearly.
This creates a challenge for the security team because they need to be able to keep pace with changes and know what security structures need to include.
Developers Can’t Catch Everything
It’s difficult, if not impossible, to catch all possible vulnerabilities before deployment. Despite the care taken during the development process, it’s unrealistic to think that developers would be aware of everything that could go wrong.
Developers also need to move quickly. Because there are always new features to add and innovations to make, security can be an afterthought for better or worse.
Traditional Security Isn’t Enough
Most FinTech companies have sophisticated runtime security stacks already. These feature multiple layers of security tools. But these solutions simply aren’t enough when it comes to API vulnerabilities.
Traditional approaches to FinTech API security, such as basic authentication, do not provide adequate protection. Because they rely on static, easily compromised credentials and do not consider the dynamic nature of API usage.
Traditional approaches often rely on static rules and signatures, which can be easily bypassed by attackers who know how to evade them.
Additionally, these approaches do not provide visibility into API activity, making detecting and responding to threats difficult.
For API security, it is necessary to use more modern security techniques specifically designed for this purpose.
Lack of skills
Appdome says lack of skills was one of the top two challenges in an organization’s API strategy. Many organizations do not specialize in app security. And there are many factors to consider: development framework, OS, security features, and more.
API security should be a top priority for fintech. They could be turbulent if you don’t know how to navigate the waters ahead. Your best bet is to find a partner to assist you in setting up the necessary security infrastructures. The peace of mind with it will be well worth the investment.
API Protection with AppTrana
AppTrana API protection is a comprehensive security solution that provides advanced protection for your APIs.
One of its key features is API discovery, which allows you to automatically identify all the APIs within your organization and track their usage. This helps you to understand how your APIs are being used and identify any potential security risks.
Another important feature of AppTrana is its positive security model, which allows only known and trusted traffic to access your APIs.
AppTrana also includes rate limiting, a technique used to control the number of requests that can be made to an API within a certain period. This helps prevent malicious actors from overwhelming your APIs with many requests, which can cause them to become unresponsive or crash.
In addition to these features, AppTrana provides real-time monitoring and reporting, so you can quickly identify and respond to any security incidents. This includes detailed logs of all API activity and alerts for suspicious activity, such as excessive rate limiting or bot fingerprinting.
APIs are a powerful tool for organizations to build innovative products and services. Research has shown that over 90% of developers use APIs and 56% have reported that APIs help them to develop better products. However, this increase in demand means there is also an increase in risk.
API security is not a new problem. It’s something that organizations have been trying to tackle for years. But as cloud computing becomes ubiquitous, we are seeing an explosion in demand for secure APIs that provide reliable access to information from different sources over different networks (and even in real time). This means that there are many more potential points of entry for malicious actors looking to exploit vulnerabilities in your infrastructure or steal sensitive data through unconventional methods.
This article highlights and expands on 7 API security related statistics you should be aware of: 41% of organizations suffered API security incidents in the past year
91% of IT professionals believe API security should be considered a priority – This report shows that 91% of IT experts believe that API security should be prioritized especially because over 70% of corporate firms are expected to employ more than 50 APIs. 8 out of 10 IT administrators desire more authority over the APIs used by their company
APIs are prevalent in SaaS models and modern applications across the board. API security refers to best practices applied to aspects of these APIs to ensure they’re protected from cybercriminals.
Web API security includes access control and privacy, as well as the detection of attacks via reverse engineering and exploitation of vulnerabilities. Since APIs enable the easy development of client-side applications, security measures are applied to applications aimed at employees, consumers, partners and others via mobile or web apps.
Why API Security Should Be a Top Priority
Attacking APIs requires first learning about a company’s APIs. To do so, bad actors perform extensive, drawn-out reconnaissance. That activity flies under the radar of existing technology such as API gateways and web application firewalls (WAFs). APIs make a very lucrative target for bad actors since they are a pipeline to valuable data and they’re poorly defended. Since data is the lifeblood of an organization, protecting it – and end-users – is paramount to avoiding breaches and the financial and reputational harm that comes with them.
In 2017, Gartner predicted API attacks would be the greatest threat to organizations in 2022. The year has arrived, and this foresight has proved accurate. Cyberattacks on APIs have exposed vulnerabilities and cost businesses a lot of time, money and heartache to recover from these breaches.
Major organizations like Peloton and LinkedIn have recently fallen victim to API-driven attacks, proving that even enterprise-class businesses (with enterprise-class budgets) are no match for cybercriminals. API attacks grew an astounding 681% in 2021, showing that businesses cannot afford to be complacent about this threat.
API Security Checklist for Development and Implementation
As with any security objective, it’s crucial to implement best practices and ensure you close all gaps in your API security strategy. While it can be overwhelming, an organized approach will help break your plan into manageable pieces. Start with scope and prioritization:
Perform penetration tests for your APIs, and know that to get a clear picture of the security status, you’ll need runtime protection
Assess the entirety of your environments, including your digital supply chain and APIs that fall outside of your API management suite
If you need to start small, prioritize runtime protection to protect from attackers while your application and API teams delve further into the comprehensive security strategy
Design and Development
Building a robust API security strategy is crucial, but that doesn’t mean you need to start from scratch. Great supportive resources, including the OWASP Application Security Verification Standard (ASVS), are available to help you design your approach.
Ensure you draft your organization’s build and integration security requirements, include business logic when performing design reviews and implement practices for coding and configuration relevant to your security stack.
Documentation
Ensure that you keep comprehensive documentation for application and integration teams. Documentation should cover security testing, design reviews, operations and protection. By documenting the stages of your process, you will ensure continuity in your testing and protection approaches.
Discovery and Cataloging
Ideally, your documentation process will be thorough and consistent. In reality, however, sometimes things are missed. Therefore, organizations must implement automated discovery of API endpoints, data types and parameters. You will benefit from this approach to create an API inventory to serve IT needs throughout your organization.
Ensure you use automation to detect and track APIs across all environments, not limiting the focus to production. Be sure to include third-party APIs and dependencies. Tag and label your microservices and APIs—this is a DevOps best practice.
Security Testing
Traditional security testing tools will help verify elements of your APIs, including vulnerabilities and misconfigurations. Bear in mind that while helpful, these tools do have their limitations. They cannot fully parse business logic, leaving organizations vulnerable to API abuse. Use tools to supplement your security strategy, and do not rely on them as a be-all-end-all view of the state of your APIs.
Security at the Front-End
For a multi-layered approach, ensure you implement a front-end security strategy for your API clients that depend on back-end APIs. Client-side behavior analytics can embellish privacy concerns while protecting the front end. It is recommended to draft security requirements for your front-end code and to store minimal data client-side to reduce the risk of reverse engineering attacks. Ensure you have secured your back-end APIs as well, as this is not an either/or approach.
Network and Data Security
In a zero-trust architecture framework, network access is dynamically restricted. It is still possible for API attacks to occur due to the connectivity required for API functionality, meaning trusted channels can still create security threats. Ensure your data is encrypted during API transport, and use API allow and deny lists if your user list is short.
Many organizations are unclear on which APIs transmit sensitive data, exposing them to the risk of regulatory penalties and large-scale data security breaches. For data security, transport encryption is suitable in most use cases.
Authentication, Authorization, and Runtime Protection
Accounting for authentication and authorization for both users and machines is crucial to a comprehensive API security approach. Avoid using API keys as a primary means of authentication, and continuously authorize and authenticate users for a higher level of security. Modern authentication tools such as 0Auth2 will increase security fortitude.
Organizations should deploy runtime protection. Make sure your runtime protection can identify configuration issues in API infrastructure. It should also detect behavior anomalies such as credential stuffing, brute forcing, or scraping attempts. DoS and DDoS attacks are on the rise, and you should be sure that mitigation plays a role in your API security strategy.
API Security is Fundamental in Today’s World
The use of APIs is a fundamental element of life in the modern era. As such, organizations have a responsibility to ensure end users, networks and data are kept safe from intruders who may expose API vulnerabilities. By following these key aspects of API security, you will be able to successfully mitigate risk.
A web API is an efficient way to communicate with an application or service. However, this convenience opens your systems to new security risks. API Security in Action gives you the skills to build strong, safe APIs you can confidently expose to the world.Â
A CISO’s mandate is to empower the business to move forward on key growth initiatives and simultaneously reduce risk. To this end, they must continuously evaluate and weigh the security ramifications of many strategic initiatives, ultimately weighing the potential impact on a company’s:
• Speed to market.
• Competitive advantage.
• Brand reputation.
By focusing on how their security infrastructure helps or hinders delivery on those three fronts, CISOs help drive business success. In today’s landscape, one new area has emerged that is integrally connected to all three of those company dynamics: the use of APIs to fuel innovation.
APIs are eating the world.
APIs are essential for companies to support their innovative and revenue-generating digital transformation initiatives. Open banking services, mobile and online services, digital information sharing apps, brands like DoorDash, Uber, PayPal, Spotify, Netflix, Tesla—you name it—all require APIs to function.
Companies are developing and pushing out APIs faster, and in larger quantities, than ever before. APIs allow companies to build and bring advanced services to market, opening up new avenues of business and revenue streams. Digitalization hastened this trend, and Covid accelerated its implementation. Companies had to quickly deploy remote services for workers and customers and build product integrations to support myriad devices—all of which demanded APIs. It’s no wonder that the public API hub Postman hit a record 20 million users earlier this year.
However, because APIs share highly sensitive data with customers, partners and employees, they have also become a very attractive target for attackers. CISOs have recognized the risk.
The faster a business can bring new services to market, the faster the benefits. For some companies (under Covid), speed to market meant the difference between keeping the business up and running versus shutting down operations. API usage ensured that organizations were open for business.
Businesses must always assess the value and the costs in terms of both achieving or losing the speed-to-market race. They must consider the obstacles that could prevent speed to market. In the case of APIs, security threats pose an enormous obstacle. They can slow down rollouts or, even worse, make them untenable.
By protecting APIs from exploitation, companies ensure their ability to drive speed to market, growth opportunities and competitive advantage.
APIs deliver a competitive advantage.
Speed to market is an important underlying factor that contributes to an organization’s competitive advantage. As an industry front runner, businesses have an opportunity to gain the lion’s share of a market and its profits.
In financial services, competitive advantage is a critical business objective, and technology transformation is its core strategic component. Fintech companies have fueled customer expectations, and open banking is right behind them, offering unimaginable innovation and conveniences by easily linking mobile apps to banking accounts.
Banking and financial institutions must stay on the cutting edge of these services to compete and stay relevant. APIs power these capabilities and allow institutions to leapfrog ahead of the competition.
However, security threats and lack of regulatory adherence can compromise successful API implementation and result in costly fines. Businesses must ensure safe passage between the emerging applications and customers’ valuable financial data. APIs represent the access point to PII and other important data assets that attackers target for their own gain and to the detriment of the business.
Dedicated API security is the cost of doing business.
The monetary growth opportunities promised by APIs are immense, but to harness them, CISOs must ensure the protection of their APIs. APIs support the interconnectivity of a company’s crown jewels—the essential and sensitive data that businesses require to deliver their digital goods and services.
Every company that is developing software has become an API-driven company. For API-driven companies, protecting those APIs is no longer a question—it’s simply the cost of doing business in a digitally transformed landscape. Without dedicated API security to protect these crucial connectivity tools, companies put everything at risk—speed to market, competitive advantage and the brand itself.
Last but not least, CISOs must build a collaborative approach to API security. APIs touch all areas of the business. CISOs need to take an active role in educating teams about their API security initiatives and their importance in reducing the company’s risks. CISOs must provide the answers and insights that empower others to help meet security goals.
CISO after CISO will tell you that creating a strong, cross-functional “security-aware” culture continues to be their number one priority. To generate this security mindset, leaders must prioritize relationships, acknowledge everyone’s contribution to security and continuously communicate the vital importance of security to achieve overall business objectives.
The OWASP Foundation recognizes this fact via the API Security Top 10 list of vulnerabilities and security risks. When we look at the list, there are six common methods of execution. Three of the issues occur due to weak access control and three to business logic abuse, with the remainder existing due to insufficient traffic management, application vulnerabilities, lack of visibility and lack of operational security readiness.
These issues are unique to APIs and make them particularly challenging to secure, so let’s look at each in detail.
1. Broken object level authorisation (BOLA)
Formerly known as Insecure Direct Object References (IDOR), BOLA allows the attacker to perform an unauthorized action by reusing an access token. This method has been widely used to attack IoT devices, for instance, as it can be used to allow the attacker to access other user accounts, change settings and generally wreak havoc much to the embarrassment of the IoT vendor.
The attack relies on the API’s resource IDs or objects not having sufficient validation measures in place. In some cases, the data used by the API has no user validation and is accessible to the public, while in other cases error messages return too much information, providing the attacker with more information on how to abuse the API.
Defending against BOLA attacks requires the validation of all user privileges for all functions across the API. API authorization should be well defined in the API specification and random/unpredictable IDs. It’s also important to test these validation methods on a routine basis.
2. Broken user authentication
An attacker can impersonate a genuine user if there are flaws with user authentication. Mechanisms such as log-in, registration, and password reset can be bombarded with automated attacks and, if poorly secured, will allow weak passwords, return error messages to the user with too much information, lack token validation or have weak or non-existent encryption.
Preventing these abuses requires security to be prioritized during development. All the authentication mechanisms mentioned above need to be identified and multi-factor authentication (MFA) needs to be applied. The development team should also look to implement volumetric and account lockout protection mechanisms to prevent brute force attacks.
3. Excessive data exposure
Some published APIs expose more data than is necessary as they rely on the client app rather than back-end systems to filter. Attackers can use this information to carry out enumeration attacks and build up an understanding of what works and what doesn’t, allowing them to create a “cookbook” for stealing data or for orchestrating a large attack at a later stage.
Limiting data exposure requires the business to understand and tailor the API to user needs. The aim is to provide the minimum amount of data needed, so the API needs to be highly selective in the properties it chooses to return. Sensitive or personally identifiable information (PII) should be classified on backend systems and the API should never rely on client-side filtering.
4. Lack of resources and rate limiting
If the API doesn’t apply sufficient internal rate limiting on parameters such as response timeouts, memory, payload size, number of processes, records and requests, attackers can send multiple API requests creating a denial of service (DoS) attack. This then overwhelms back-end systems, crashing the application or driving resource costs up.
Prevention requires API resource consumption limits to be set. This means setting thresholds for the number of API calls and client notifications such as resets and lockouts. Server-side, validate the size of the response in terms of the number of records and resource consumption tolerances. Finally, define and enforce the maximum size of data the API will support on all incoming parameters and payloads using metrics such as the length of strings and number of array elements.
5. Broken function level authorization
Effectively a different spin on BOLA, this sees the attacker able to send requests to functions that they are not permitted to access. It’s effectively an escalation of privilege because access permissions are not enforced or segregated, enabling the attacker to impersonate admin, helpdesk, or a superuser and to carry out commands or access sensitive functions, paving the way for data exfiltration.
Stopping this level-hopping activity requires authentication workflow to be documented and role-based access to be enforced. This requires a strong access control mechanism that flows from “parent to child” and doesn’t permit the reverse.
6. Mass assignment
The attacker discovers modifiable parameters and server-side variables that they then exploit by creating new users with elevated privileges or by modifying existing user profiles. This can be prevented by limiting or avoiding the use of functions that bind inputs to objects or code variables. The API schema should include input data payloads and enforce segregation by whitelisting client-updatable properties and blacklisting those that should be restricted.
7. Misconfiguration
Incomplete, ad-hoc or insecure default configurations, misconfigured HTTP headers, unnecessary HTTP methods, permissive cross-origin resource sharing (CORS), and verbose error messages containing sensitive information are, unfortunately, all too common in APIs. They’re usually the result of human error, due to a lack of application hardening, poor patching practices or improper encryption and, when discovered by an attacker, can be exploited, leading to fraud and data loss.
Configuration is all about putting in place the right steps during the API lifecycle, so it is advised to implement a repeatable hardening process, a configuration review and update process, and regular assessments of the effectiveness of the settings. Defining and enforcing responses (including those for errors) can also stop information getting back to the attacker. CORS policies should also be put in place to protect browser-based deployments.
8. Injection
A staple of the OWASP Web Application top 10 list, injection attacks see the untrusted injection of code into API requests to execute commands or to gain unauthorized access to data. These attacks can happen when the database or application lacks filtering or validation of client or machine data, allowing the attacker to steal data or inject malware by sending queries and commands direct to the database or application.
The mitigation of injection attacks requires separation between data/commands and queries. Data types and parameter patterns should be identified, and the number of records returned should be limited. All the data from clients and external integrated systems should be validated, tested, and filtered.
9. Improper asset management
Poorly secured APIs such as shadow, deprecated, or end-of-life APIs are highly susceptible to attack. Other threat vectors include pre-production APIs that may have been inadvertently exposed to the public, or a lack of API documentation that has led to an exposed flaw, such as authentication, errors, redirects, rate limiting, etc.
Here it’s critical to look at the API publication process by replacing or updating risk analyses as new APIs are released. Continuous monitoring of the entire API environment, from dev to test, stage and production, including services and data flow is also advised. Adopting an OpenAPI specification can help simplify the process.
10. Insufficient logging and monitoring
Attackers can evade detection entirely if API activity isn’t logged and monitored. Examples of insufficient logging and monitoring include misconfigured API logging levels, messages lacking detail, log integrity not being guaranteed, and APIs being published outside of existing logging and monitoring infrastructure.
Logging and monitoring need to capture enough detail to uncover malicious activity, so it should report on failed authentication attempts, denied access, and input validation errors. A log format should be used that is compatible with standard security tools and API log data should be treated as sensitive whether in transit or at rest.
Unique challenges
All ten attack methods reveal how difficult it can be to secure APIs, which are continuously being spun-up, updated or replaced, sometimes daily. In fact, they’re so numerous that their security can only be enforced using automation. Consequently, many organizations have tried to use rules-based security solutions and code-scanning tools, although these are not equipped to spot the types of abuses identified in the OWASP list. Web application firewalls (WAFs), for instance, offer limited protection because they look for known threats, while an API gateway can create more problems by acting as a single point of failure.
It’s for these reasons that Gartner recently created a distinct API security category, separate from these other tools, in acknowledgement of the fact that APIs have their own set of problems (that are also often unique to the business itself).
In the “Advance your Platform-as-a-Service Security” report, analyst Richard Bartley reveals API security tooling for API discovery and protection should be regarded as having equal importance to and sit between internet edge security (i.e., WAF) and the data plane security layers (i.e., the Cloud Workload Protection Platform or CWPP). This new breed of API security is therefore cloud-native and behavior-based, allowing it to spot and respond to API-specific anomalous activity.
These new tools specifically focus on the prevention of automated attacks against public-facing applications and the persistence of API coding errors. They use machine learning to analyze APIs and web applications coupled with behavioral analysis to determine whether the intent behind API interaction is malicious or benign. They can also act by blocking, rate limiting, geo-fencing and even deceiving attackers, thereby buying time to respond. Such capabilities mean that API-specific security solutions can be applied to aid the developer and to monitor the security of the API throughout its entire lifecycle, thereby preventing the automated attacks and vulnerability exploits identified in the OWASP API Security Top 10.
With APIs continuing to outstrip web apps in the rollout of new services, we must attend to how these are secured or risk building these services on shaky foundations. The hope is that with the OWASP Project highlighting how APIs can be exploited and Gartner creating a distinct new category, the tech sector will finally realize that API security is an anomaly that merits its own solution.
IBM Security Services today published a report detailing a raft of issues pertaining to cloud security, including the fact that there are nearly 30,000 cloud accounts potentially for sale on dark web marketplaces.
The report is based on dark web analysis, IBM Security X-Force Red penetration testing data, IBM Security Services metrics, X-Force Incident Response analysis and X-Force Threat Intelligence research.
The report found advertisements for tens of thousands of cloud accounts and resources for sale. Prices generally range from a few dollars to over $15,000 per account for access credentials depending on the amount of cloud resources that might be made accessible. On average, the price tag for cloud access rose an extra $1 for every $15 to $30 in credit the account held. Therefore, an account with $5,000 in available credit would be worth about $250, the report surmised.
In 71% of cases, threat actors offered access to cloud resources via the remote desktop protocol (RDP). X-Force Red found that 100% of their penetration tests into cloud environments in 2021 uncovered issues with either passwords or policy violations. Two-thirds of cloud breaches would likely have been prevented by more robust hardening of systems, such as properly implementing security policies and patching systems, the report noted.
More troubling still, IBM research indicates that vulnerabilities in cloud applications are growing, totaling more than 2,500 vulnerabilities for a 150% increase in the last five years. Almost half of the more than 2,500 disclosed vulnerabilities in cloud-deployed applications recorded to date were disclosed in the last 18 months.
The report also notes two-thirds of the incidents analyzed involved improperly configured application programming interfaces (APIs), mainly involving misconfigured API keys that allowed improper access. API credential exposure through public code repositories frequently resulted in access into cloud environments as well, the report noted.
Think of APIs as the new network; interconnected in complex ways and with API interactions happening both within and outside of the organization.
“Public-facing APIs—for example, consumer banking—are usually a key area of focus when it comes to zero-trust,” said Dunne. “This is due to the obvious risk exposure when APIs are documented and made available on the public internet.”
However, the larger risk is found in private and internal APIs, because there is a common assumption that since they aren’t documented or found on a public network, they aren’t exposed.
But as threat actors become more sophisticated in their search for and discovery of private APIs, there is increased risk of the bad guys gaining access to massive amounts of sensitive data. Private APIs need the same layers of protection as public-facing APIs.
“APIs are, by definition, atomic in nature—meaning they can be invoked independently,” explained Setu Kulkarni, vice president, strategy at NTT Application Security in an email interview. “That creates a real challenge for securing these APIs.”
Given that, Kulkarni added, a critical consideration for implementing zero-trust in APIs is to ensure that there is appropriate access control built into the API implementation. Every API function call requires not just authentication but also authorization. Also, adding zero-trust around session validation helps to prevent unintended data leakage.
