3 things you need to know about API protection

By Gaia Lamperti

Open Banking is the undisputed megatrend of financial services this year. But with immense benefits favoured by the shift to open APIs, also come new risks and challenges. Cybersecurity providers are now stepping up their game when it comes to API protection, offering tailored solutions to protect the security and privacy of financial firms’ data.

IBS Intelligence had a chat with Terry Ray, Senior Vice President and Fellow at Imperva, a leader company in data protection and API security. “For consumers, Open Banking offers a host of benefits, from greater control over their data to the ability to manage their finances more efficiently,” Ray explained. “For businesses, it has opened up new revenue opportunities for banks and FinTechs, attracting more than 2.5m customers in the UK.”

But while a huge driver of innovation and competition, Open Banking also poses security risks. “Last year, dozens of high-profile data breaches originated from API security-related incidents. Attacks often resulted in data leakage, data scraping, access exposure, end-user tracking, account takeover and more,” Ray pointed out. He shared 3 essential aspects that companies need to keep in mind when addressing security in the context of Open Banking.

1. The more APIs, the more gateways for cyberattack 

“Because financial firms must now share customer data with third parties via open APIs, the attack surface has grown dramatically, yet they still have to maintain the security and privacy of that data. Moreover, since APIs grant access to customer data and sensitive financial records, they are becoming one of the most attractive entry points for cyber-criminals.

The biggest problem for banks is the explosive growth in the number of APIs being used. It’s estimated that open banking APIs increased from 1.9 million monthly interactions in June 2018 to 694.4 million in December 2020, many created by development teams without knowledge or oversight from security. The more APIs banks have, the more gateways there are to access sensitive data, and the harder it is to ensure APIs are properly secured.”

2. Hackers can exploit a number of vulnerabilities for different attacks

“APIs often self-document information, such as their implementation and internal structure, which can provide valuable intelligence for a cyber-attack. Additional vulnerabilities, such as weak authentication, lack of encryption, business logic flaws, and insecure endpoints make APIs vulnerable to attacks such as:

• Man In The Middle (MITM) attacks: An unencrypted connection between the API client and the API server can expose a lot of sensitive data to hackers. For example, a perpetrator can lurk between a website and a user browser. Intercepting traffic between the two could grant access to the user’s account, which might include details such as credit card information and login credentials.
• API injections: It’s possible for attackers to simply inject malicious content that could lead to exploits. For example, a perpetrator can inject a malicious script into a vulnerable API to launch an attack targeting end users’ browsers.
• Distributed denial of service (DDoS): In a DDoS attack, multiple systems flood the bandwidth or resources of a targeted system. For example, a DDoS attack on the FCC website in early 2017 used commercial cloud services to issue a massive amount of API requests to a commenting system. This consumed available machine resources and crowded out human commenters, eventually causing the website to crash.”

3. There are multiple ways to secure your APIs

“APIs need to be provided with the same level of protection businesses give to business-critical web applications. This includes:

• Visibility: Gaining visibility across all API endpoints is key to securing them.
• Understanding end-users to ensure authentication and authorisation: Determining the identity of end-users and what they need access to is key to securing APIs and implementing authentication. APIs should be built and tested to prevent users from accessing API functions or operations outside their predefined role. For example, a read-only API client shouldn’t be allowed to access an endpoint providing admin functionality.
• Understanding API behaviour: Just as there needs to be controls in place on what users do, businesses need to understand APIs and how they behave, identifying unusual behaviour that could be a sign of malicious activity.

Beyond security controls, organisations today need to ask about comparative API risk. Which APIs access sensitive or regulated data? How much of that data do they access? Is that normal for an API? How does that behaviour compare to other APIs?  With the volumetric growth of APIs in FSI, it’s no surprise that these risk-oriented questions are becoming more prominent.  IT audit examiners have already begun much more detailed examinations of security teams’ awareness of how APIs interact with sensitive systems.”