By Filip Verloy, Technical Evangelist EMEA, Noname Security

Open banking is the perfect example of API-led digital transformation. APIs are the plumbing in today’s financial infrastructure that enable fintechs to embed banking into their apps, and banks to offer a more unified experience to their customers as they demand more from their incumbent financial services provider.

This cycle of continuous innovation is propelling the use of APIs across the sector, allowing third-party developers to develop apps around a particular financial institution. However, the speed at which fintechs and traditional banks are bringing these services to market means their security will be inadvertently tested.

Innovate to compete

Traditional banks must compete against digital neobanks today and keep up with new consumer demands. They are rushing to deploy new technologies that enable frictionless digital experiences. Globally, open banking programmes have driven API-centric services which are opening payments, account services, and other customer data to third party providers. The effort to attract new, and keep existing, customers by delivering additional value has resulted in more application services and supporting APIs. This increased adoption of API use has resulted in a dramatic increase in the attack surface they present to attackers and other bad actors.

Security should not be an afterthought. Whether it is pursued as a compliance requirement or a business strategy, ensuring the organisation does not become synonymous with a data breach should always be a priority. Therefore, API security needs to be top of mind when it comes to the app development process. However, many financial services and fintech companies have opted to not develop their apps internally and instead, have outsourced their API and mobile app development to third parties.

Noname Security recently published research findings based on ex-hacker Alissa Knight’s analysis of security across 55 mobile banking apps in the US. The takeaways are as relevant to the UK market as the US. Scorched Earth: Hacking Bank APIs highlighted several vulnerabilities:

• 54 of the 55 mobile apps that were reverse engineered contained hardcoded API keys and tokens including usernames and passwords to third-party services.
• All 55 apps tested were vulnerable to ‘woman-in-the-middle’ (WITM) attacks, allowing Knight to intercept and decrypt the encrypted traffic between the mobile apps and backend APIs.
• One of the banks outsourced the development of its mobile app and APIs. That developer re-used the same vulnerable code affecting 300 of its other bank customers.
• 100 percent of the APIs tested were vulnerable to OWASP API1:2019 Broken Object Level Authorization (BOLA) vulnerabilities, allowing Knight to change the PIN code of any bank customer’s Visa ATM debit card number and transfer money in and out of accounts.
• Due to a failure to authenticate the API requests, the APIs tested were also vulnerable to OWASP API2:2019 Broken Authentication, which allowed Knight to transfer money in and out of different bank accounts and change customer ATM debit PIN codes as long as she knew the account numbers without authentication.
• APIs were deployed behind web application firewalls (WAFs) — the wrong security control. It is incapable of detecting logic-based attacks like authentication and authorisation vulnerabilities.
• During several of the engagements, some of the banks were unable to find specific API endpoints affected by the vulnerabilities indicating a clear visibility problem into their API attack surface.

It’s clear, based on these findings, that authentication and authorisation are very much broken; there is still some way to go towards a ‘zero-trust’ model when building API-led services. Performing pre-production API security validation is paramount.

Fixing the API security problem

API security vulnerabilities affect all enterprises, but perhaps the financial services sector is the most sensitive. After all, security strikes at the heart of people’s confidence in banking so this is critical to its continued success and adoption.

In Alissa Knight’s research, she found the same API security vulnerabilities in banks that had 25,000 customers and a few million dollars in managed assets, as she did in banks that had 68 million customers and $7.7 trillion in assets under management. Large, mature, and well-funded security teams are not able to keep pace with the API security challenges with traditional tools and processes.

API security must be operationalised across financial services

Many teams play critical roles in securing APIs. Developers need to write code with security in mind; cloud and platform teams need to use APIs that are configured properly; and security teams need to detect, investigate, and respond to incidents quickly. Often, especially in larger organisations, APIs are deployed to production faster than they can be secured and there often isn’t a clear line of communication across enterprise teams.

Specific to Knight’s research, the APIs she exploited were developed by a third party — introducing yet another variable. Furthermore, the hack wasn’t detected at any of the banks. This highlights the fact that API security needs to be operationalised across more enterprises to ensure that vulnerabilities are detected and remediated before an attack occurs. And it’s not just the responsibility of a single team. Developer, DevOps, DevSecOps, and security teams need to standardise, collaborate, and communicate how they build, deploy, and secure APIs.

It’s easy to jump to conclusions when exploits or attacks make headlines but detecting and blocking behaviour like Alissa Knight’s is only a piece of the API security puzzle. Enterprises need to think about API security across 3 core areas:

1. API Security Posture — organisations need a complete API inventory (including associated data and metadata), so they have a stronger sense of their security posture. It’s imperative to identify and remediate misconfigurations and vulnerabilities before an incident occurs. As evidenced in Knight’s research, many organisations are completely exposed and won’t be aware until after an attack has occurred.
2. API Runtime Security — organisations need better visibility into the traffic and behaviour of their APIs. This provides better detection and response to anomalous and suspicious behaviour so attacks can be prevented in real-time when something out of the ordinary occurs.
3. API Security Testing — organisations need to identify security gaps as part of the software development lifecycle. For example, at no point should business-critical APIs be deployed into production if they couldn’t pass basic security checks (e.g., lack of authentication). Active testing ensures confidence in your APIs throughout the lifecycle of an API.

Balancing innovation and security

As the banking sector continues to adjust to the new market environment, those institutions that adapt to new technologies will have a better chance of long-term success. Open banking is a foregone conclusion, and the current ecosystem will be replaced by new frameworks of digital tools. Banks must develop, not just a new vision of their place in the new financial services infrastructure, but also a fresh perspective on how they can ensure these digital tools are secure and resilient against various attack vectors to protect both themselves and their customers.