The only automated NLP-based API security platform that protects enterprise applications at scaleLearn More »
I can vividly remember as a kid visiting our local bank with my grandparents. The bankers were dressed up in neat dark suits, and only white or blue dress shirts were allowed. And ties, of course. We used to wait patiently in line to meet with the teller, our very own customer relations manager. Those were the days when personal touch was oh so important and we couldn’t really imagine performing any financial transactions on our own.
But beyond the pleasant fog of reminiscing, we had to physically go for every single inquiry – Even if we only wanted to check the balance of our savings account. To me it didn’t matter, it’s like not I had anywhere else to be or something else to do, but I’m pretty sure my grandparents didn’t like it as much. Now that the banking industry joined the digital roller coaster, both consumers and financial professionals are going through a massive transformation as well.
Digital banking is rapidly becoming the standard, and we have all become used to conducting our financial activities remotely and instantly. Banks offer a wide range of services and invest significant resources in providing a compelling user experience, as customers’ expectations of the quality and variety of services available through digital channels are on the rise.
Competitive pressure is a key driver of this massive transition to digital banking, and there seems to be a digital “arms race” between many banks looking to leverage digital activities as a competitive advantage. In fact, 85% of banks cited the implementation of a digital transformation program as a business priority in this Global Banking Outlook conducted by EY in 2018.
Open banking is becoming a major source of innovation that is poised to reshape, yet again, the banking industry. Open banking, also known as “open bank data”, is a banking practice that uses application programming interfaces (APIs) to provide third-party financial service providers with access to consumer banking, transactions, and other financial data from banks and other financial institutions. A recent Finastra research among 774 banks worldwide reveals that 86% of global banks are looking into APIs to enable Open Banking capabilities within the next 12 months.
Under the open banking convention, customers are typically required to grant some kind of consent in order to allow their bank to give access to third parties (e.g., checking a box on a terms-of-service screen in an online app). Through APIs, third-party providers can then access and use customer data. Uses might include comparing the customer’s account and transaction history to a range of financial service options, aggregating data across participating financial institutions and customers to create marketing profiles, or making new transactions and changes to accounts on behalf of the customer.
When it comes to APIs open to 3rd party partners, these represent potentially a greater risk than the bank’s web application API (consumed by their own web app) or their mobile application API (consumer by their own mobile app). For APIs open to third parties, banks don’t enjoy the same level of visibility to the front-end application using their API and have less control and tools to detect and block fraud or malicious traffic.
Here’s an example of an API data breach that is 100% API driven. This attack exhibits sensitive data theft using one of their APIs:
In normal use, after a successful authentication process via web or mobile application, the user receives a list of phone numbers associated with their investment account from which they can choose to perform an action. In the attack scenario, the attacker bypassed the application and manipulated the API directly using the credentials of a legitimate user and a random selection of phone numbers.
Using valid credentials, the attacker logs into the system then scans a large range of phone numbers. The API backend server does not validate that the phone belongs to the authenticated user, and as a result, the attacker receives the customer’s information, including sensitive information like a home address and identification numbers.
Known as Broken Object Level Authorization (BOLA), this is a common attack method, often resulting in substantial damage to the organization’s reputation and exposure to privacy regulation violations.
Had the bank had greater visibility into what sensitive data their API exposes or uses, they could have added dedicated protections and verification logics in their API for these scenarios.
The open banking revolution is well on its way, heavily relying on APIs. As such, APIs are becoming a growing attack surface, exploited by hackers who identify specific flaws in design and software bugs in the implementation of a system. These vulnerabilities can then be used to attack an organization’s core assets. Such attacks cannot be detected by currently available, general-purpose application security tools.
The first step towards API threat prevention is gaining visibility so that any use or exposure of such data is better protected throughout the lifecycle. Digital organizations that use APIs to expose sensitive data and enable sensitive transactions must consider adding a dedicated and specialized API security layer to protect against API-targeted attacks.