Open banking and APIs: the security challenges

By Yaniv Balmas, VP of research at Salt Security

Open banking is here to stay. It provides consumers with improved access to their money and financial data, and it creates new opportunities for financial companies to innovate. Thanks to open banking, consumers can avail themselves of new, differentiated services, and ultimately have more control over their financial lives.

At the core of this democratisation of banking across the globe are Application Programming Interfaces (APIs), which enable, streamline and connect the flow of financial data between financial institutions.

But while there are some standards around the data formats or predictable integrations that an API should provide, open banking still enables only a relatively low bar in terms of security requirements. Authentication, authorisation, and encryption are typically the main parameters addressed in open banking, and these focus areas only scratch the surface of complex security challenges created by APIs. To compound matters, the best practices for the implementation of authentication and authorisation are only loosely defined, as is common with many standards or regulations. As a result, real world implementations are left open to interpretation resulting in uniqueness across providers.

One of the logical flaws of these basic security parameters is the distinct ways in which organizations implement business logic through an API, which makes each instance unique. This makes it virtually impossible to standardise parameters for the implementation of authorisation. We also still observe cases where some financial services providers will block access from financial technology providers, effectively defeating open banking. The combination of different services under the open banking umbrella also means that multiple APIs are made to interact, resulting in unique APIs with unique logic connecting to other unique APIs with unique logic. This ultimately results in a distinct set of vulnerabilities specific to each combination of APIs and resulting API calls.

With this premise, it should be no surprise that APIs are being targeted by cybercriminals more than they ever were. A few years ago, Gartner predicted that, come 2022, API abuses would become the most frequent attack vector, resulting in data breaches for enterprises and web applications. In the second half of 2021, Gartner revised their prediction to say that it expects API abuses and related breaches to double by 2024.

One of the easiest bars for attackers to step over is, of course, authentication. Legitimate login details can be obtained fairly easily since phishing is still effective at stealing people’s credentials. Should these approaches fail, brute force and credential stuffing attacks used to compromise accounts or achieve account takeover remain an option to allow an attacker to make their way into an API. Attackers also use other techniques like harvesting API keys from application code or hijacking authenticated session identifiers.

At that point of an attack sequence, encryption becomes almost superfluous, as it is employed largely to protect data in transit or at rest. An authenticated, authorized user can easily access unencrypted data directly from the endpoint without having to devise a more complicated person-in-the-middle approach.

Authorisation should then come into play to control what functionality or data a given user or machine has permission to access. In theory, this should create a solid barrier against API abuses. In practice, however, getting authorization right is incredibly difficult, as the OWASP API Security Top 10 reflects: Broken Object Level Authorization is the number one flaw on the list and the most ubiquitous API vulnerability.

There are numerous reasons why API authorisation is difficult to get right. APIs’ often implement complex business logic, and the combination of multiple APIs – often developed by multiple internal and external teams with varied design approaches – creates an extremely complicated and distributed environment. Banking APIs are a prime example of such complexity realized.

Furthermore, authorisation has several dimensions for consumption patterns and user types, from customers to partners and developers. All these levels need to be carefully considered when defining an authorisation policy. In the absence of sufficient subject matter expertise when considering all the business cases and potential impacts, organisations will often steer towards relaxed access controls so that systems can continue to function without negative business impact.

The ever-changing nature of APIs further complicates the matter, as new functionalities are created or updates are installed frequently such as with cases of acquired software or componentry. Each update has a bearing on the overall logic of the API and its integrations, which can also impact authorisation requirements. Synchronizing policies to enforce authorisation without making mistakes becomes difficult, if not impossible. And rarely is there one touch point for access control configurations when considering the entirety of a given digital supply chain.

Other than authentication, encryption, and authorisation, traditional security tools of the trade such as WAFs and API gateways also fail to sufficiently protect APIs. The problem is in the architecture of such tools or controls. These security mechanisms examine API transactions in isolation, which limits their ability to gain the context necessary to detect today’s ‘low and slow’ attacks that target and abuse APIs.. When it comes to APIs, signatures, and policies employed by WAFs and gateways are insufficient to detect and stop most malicious traffic because of the uniqueness of each API’s logic and vulnerabilities. Creating and maintaining policies for each unique API is also a near-impossible quest, given the speed at which APIs change. Many organisations have already conceded such rule maintenance to vendors, service providers, or MSSPs when attempting to protect their web applications, let alone APIs.

How can we protect banking APIs?

To protect banking APIs, a fundamental shift must take place in how participating organizations approach API security. Financial services providers must consider newer architectures that emphasize big data and AI/ML approaches to capture and analyze large amounts of API traffic in order to detect and stop API attacks. Security capabilities must also benefit other API life cycle activities including continuous discovery to detect deltas in API environments, automated security posture assessment to uncover API misconfigurations or flaws, and tailored feedback for API teams with guidance on how to remediate any detected API issues. Organizations can’t afford to look at transactions in isolation as traditional technologies like API gateways or WAFs support, nor can they rely on authentication, authorization, and encryption alone. Gaps in API security posture leave customer credentials at risk and potentially enable fraudulent activity.

Shadow, forgotten, and zombie APIs

Visibility is key to understanding an organization’s attack surface and implementing a successful security strategy, and this holds true for APIs. Not only should an API security strategy keep track of the constant changes in APIs, but it should also be able to uncover unknown, referred to as shadow, and forgotten, referred to as zombie APIs, through continuous discovery to uncover newly released and updated APIs. Automation is essential to keep track of APIs, which are often in the thousands within a single organisation when including API endpoints or functionality within a given endpoint. Each of these APIs should also be understood at a granular level so that security teams can keep track of its critical functionalities and/or where personal identifiable information could potentially be exposed.

Relying on API documentation created during design and development phases, if such documentation processes even exist, leads to inaccurate and incomplete information, especially when it comes to updates and new releases. Documentation is often not created at all, not maintained consistently, not generated in machine formats, or filled in at a later date. This has, of course, serious implications, not only for security teams but also for API reusability within an organisation or by its partners.

How to stop API attacks

As mentioned, for financial institutions to better secure APIs, they can adopt an approach that utilises big data and AI/ML to capture traffic, define baselines of normal activity, and identify any deviations from such baselines. It must be said, however, that anomalies alone aren’t sufficient indicators of malicious activity, as they can be caused by a variety of innocuous factors, such as user mistakes, changes to an API, or unique users and partners.

Effective solutions must combine context and correlation. Building a profile for each user can discriminate between isolated incidents, changes in APIs, and patterns of malicious activity. Correlating API activity with each user session or profile also helps reduce false positives, as the thresholds for alerts can then be set by risky deviations on the activity of each specific user, rather than a more generalized, less accurately defined baseline.

Combining context and correlation also anticipates detection, as malicious traffic can be predicted on the basis of potentially suspicious activity, rather than on predefined signatures that can only identify known threats or well-defined patterns.

Putting Security into DevOps, DevSecOps

Software has bugs, no matter how competent and security-aware developement teams may be. Scanning tools and training help, but mistakes happen, especially with software that undergoes frequent changes and release cycles like APIs. For this reason, runtime protection and prevention is critical to mitigating the risk posed by API vulnerabilities or abusable business logic that make it to market. Alone, however, runtime protection can turn into a sort of whack-a-mole game, where application development teams need to continuously find and fix security bugs.

A dedicated API security solution can greatly improve the insight needed by development teams to remediate vulnerabilities according to the risk they pose in a real-world context. Details on what normal usage of the API looks like, together with recommendations on how to close security gaps, are essential to inform the prioritisation of security fixes and ensure that vulnerabilities are patched before an attacker has the chance to exploit or abuse them.