top of page
Search

Security Considerations for Open Banking APIs


Partner Post by Francois Lascelles, VP and Chief Architect at Axway.


Register here: Open Banking Security and Governance Webinar


The use of APIs by fintech and financial institution is not new, but the open banking trend is accelerating the deployment of these APIs. As banks are top cyberattack targets and APIs are becoming a main attack vector, security and privacy need to raise to the top of the list of requirements for the infrastructure supporting these APIs.


APIs are an attractive attack target not only because they are the gateway to sensitive data but also because disrupting them can affect banking services and take down banking apps. The potential consequences of a breach on online banking services are numerous. They include:

  • Reputation loss

  • Regulatory fines

  • Data loss

  • Identity theft

  • Money laundering

  • Financing terrorism


In jurisdictions where open banking regulations are applicable, some security standards are formalized. For example, PSD2 defines Strong Customer Authentication (SCA). The SCA requirement is meant to reduce fraud and make online and contactless offline payments more secure. To accept payments and meet SCA requirements, you need to build additional authentication into your flow. In other areas, not impacted by similar regulations, PSD2 guidelines can serve as a reference for the establishment of security objectives. However, don’t expect any of these standards to provide an exhaustive list of security precautions for your banking APIs. Ultimately, you are responsible for defining and implementing the security of your banking APIs. Here are a few things to consider:


Define API security objectives

Based on applicable regulations, on the sensitivity of the data going through your APIs, on the potential impacts of an API going down, define what the objectives of each API should be first. This ideally occurs in the design phase of an API but most often happens after the fact. Don’t assume that an API is properly secured just because it’s been in prod for a while.


Discovery, Inventory

You can’t secure what you’re not aware of. Because APIs are sometimes considered an implementation detail in an application, their existence is not always known outside the development team. Expect new APIs to be created over time. API discovery should be an integral part of API security. Have a process through which your API inventory is refreshed on a regular basis so that you can assess current security measures and compare with your security objectives.


Security testing at the API layer

Because apps call APIs on behalf of users, what goes over the wire is most of the time hidden. Security testing at the API layer helps address blind spots. For example, an API will often return much more data than is displayed by an app. A helpful reference for API security is the owasp API security top 10 list of vulnerabilities which defines “excessive data exposure” as number 3 on its list. Going through this list for your APIs will help you define tests that checks for common bugs in your APIs that can then be exploited by attackers.


Make it easy to adopt

The developers of your APIs shouldn’t have to reinvent security mechanisms for each API. Security policies can be templatized and enforced in API infrastructure on behalf of the APIs themselves using for example API gateways. These security templates should be easy to adopt and apply to new APIs. When friction is associated to applying API security, developers who are under pressure to deliver new functionality faster will look for work-arounds, potentially compromising the best security intentions.


Orchestrate API security across key components

API security involves numerous components that need to work together to secure APIs while maintaining a great UX. For example, API gateways will integrate with Identity management infrastructure, monitoring and analytics tools receive data from API gateways and other edge components through which API traffic flows, specialized AI engines analyses historical accesses to spot anomalies and evaluate risk based on context.


Monitoring, auditing

API monitoring falls under two categories: external and internal monitoring. Monitoring from the outside lets you validate that your APIs are available and that they perform well. Monitor and auditing from the inside lets you track what each client is doing.


Well secured open-banking APIs are a key component for financial institutions to increase their digital maturity and to stay competitive in a challenging market.





Join us for our upcoming webinar to learn more

Date and Time: August 11, 2021, 11am MT / 1pm ET

Speakers:

Francois Lascelles, VP and Chief Architect, Axway

Reuben Piryatinsky, CEO, Altitude Consulting



95 views0 comments

Recent Posts

See All
bottom of page