By Travis Spencer, CEO, Curity

APIs form the web’s infrastructure; they create the business behind big business. A running app’s map interface, an online florist’s payment system, a recruitment firm’s group video call function — these are all examples of APIs, or Application Programming Interfaces, helping businesses meet customers’ needs. But as the rapid growth in cloud computing continues, it’s clear that APIs are front and center in driving digital transformation and business revenue and will remain so for years to come. To get a sense of the increasing importance of APIs in sectors like finance you need only consider Stripe, the digital payment firm valued at $95 billion earlier this year to become the US’s most valuable private enterprise, or Visa’s thwarted attempt to acquire Plaid, the nascent banking API, in 2020 for $5.3 billion. If the rise of SaaS made businesses realise that their IT systems didn’t need to be proprietary, then APIs have supercharged the move away from in-house software solutions.

The benefits of API for future-facing financial organisations are obvious. APIs allow legacy banks and digital upstarts alike to offer customers a responsive, fit-for-purpose online service. Software developers can use APIs to innovate at speed in a user-centric way. The rich streams of user data that APIs can yield will only further enhance those goals, creating a virtuous circle. For firms that take insufficient care with API security, however, these rewards are loaded with risks. While APIs present ample opportunity for growth, fintech organisations have a special responsibility to ensure the safety of API-enabled transactions. They must ensure  that data breaches aren’t made easier by the presence of APIs in an app’s software architecture. We can only do that with banking-grade infrastructure that adheres to best security practices.

GDPR and the impact on the API economy

Before exploring this, it’s important to note the impact of GDPR. Since its introduction in 2018, organisations have had to overhaul their approach to handling personal information. (The UK currently operates under the same framework for now.) The immediately obvious impact on financial companies has been the threat of severe penalties for regulatory breaches Though such firms are far from the worst offenders, two Spanish banks were fined a total of $11.5 million in December 2020 and January 2021 for breaking GDPR rules. Those rules also cover obtaining explicit consent from customers (which is why you see pop-ups on websites asking for your permission to use cookies) and the so-called ‘right to be forgotten’.This right means that firms can no longer store your data in perpetuity without a good reason.

The GDPR rule most salient to the API economy, however, may be the one governing vendor management. This grants the user the right to control  how personal information circulates through IT systems. Personal data is  increasingly streaming out of GDPR-controlled organizations  through APIs. Without firm guardrails, such systems expose organizations to risk. Weak spots might include broken object level authorization which means the system cannot properly confirm a user’s access privileges. Another issue  is broken user authentication, a situation in which bad actors impersonate users with the required authorisation. Unprotected APIs are also vulnerable to Denial of Service (DoS) attacks. Granting administrators too many rights (i.e., mass assignment) can lead to exploitation if those accounts fall into the wrong hands. Security misconfiguration, code injections, improper assets management and insufficient logging and monitoring are other key API pain points identified by the Open Web Application Security Project (OWASP).

The list of dangers is long, but the good news is that banking-grade solutions for such API security problems already exist. These are built around OAuth which is an open standard for access delegation and is leveraged as a means for users to grant websites or mobile applications access to their information without sharing passwords. On top of this standard, financial-caliber APIs utilize OpenID Connect. This is an identity layer that allows applications to verify the end-user identity based on authentication performed by an Identity Provider (IdP or authorisation server). The identity and API access tokens issued by this IdP include “scopes” and “claims” that allow IT systems and APIs to precisely control the degree and nature of access to personal information. This prevents many of the security weaknesses mentioned earlier as well as other common API flaws. (In organisations with complex hierarchies, the improper assignment of permissions among different user groups can be avoided using scopes and claims as defined in the  OAuth and OpenID Connect.) The usefulness of these standards in addressing GDPR-compliance issues and API security challenges, more broadly, can be boiled down to three techniques:

1. The acquisition of explicit consent;
2. Utilization of Pairwise Pseudonymous Identifier (PPID); and
3. Phantom Tokens.

A PPID is an unguessable user ID with no overt association with the details of the actual user. Phantom tokens are tokens that are only accessible within a private network. They are typically mediated from an opaque, handle-token by an API or ZTNA gateway. This brokerage converts the reference to the actual identity data into a full-blown token that back-end APIs can use to perform authorization without exposing the sensitive user data within it beyond the private network.

The implications of privacy regulations on the Open Banking space are undoubtedly good for consumers across the globe. Around the world, there are a number of privacy regulations in place such as Europe’s GDPR, including Australian Privacy Principles (APP), Brazil’s LGPD and South Korea’s PIPA.

The regulations have forced fintechs to take data privacy far more seriously. This  has seeded serious investments in API cyber security and a much wider discussion on the importance of explicit consent in Open Banking. Improved API security instils confidence in customers that regulation-compliant firms will handle their data with care and seek explicit consent from customers in all situations. This, in turn, is more likely to cultivate customer loyalty. Allegiance is a precious commodity in Open Banking, since customers, faced with more choice than ever, will feel more empowered to be picky and switch banks in the digital era. It may seem that these regulations are designed to make life harder for banks, but that’s not necessarily the case. The regulations, for instance, streamline the framework in which banks operate by standardising security protocols on a global level. This makes compliance much easier for financial institutions.

Organisations will have to treat GDPR as a challenge to be met rather than a burden to be shouldered. Non-compliant firms can be fined either €20 million or 4% of global annual turnover. This should be motivation enough. Being on the right side of GDPR isn’t cheap either. The cost of compliance for UK FTSE 100 banks, as a recent report by Statista outlines, is more than triple that of the next closest sector (nearly €80 million). Whether a bank decides to hire a GDPR specialist or outsource that work to a third party, an organisation that successfully navigates the GDPR maze will need to show a commitment beyond the bare minimum. This will require on-going risk assessments, stress testing, properly trained staff, and deploying up-to-date technology.

Consider the common-sense element

Where the API economy is concerned, following the right strategies will help companies get the most out of its rewards while minimising the risks. Installing an API gateway will centralise traffic features, enabling better control of requests that affect both security and business concerns. A dedicated OAuth server that issues tokens is more secure than tokens issued at multiple points across the system. Combining opaque tokens with JSON Web Tokens (JWTs) will optimise safety and convenience if your system is communicating with both internal and third-party clients. Scopes and claims can allow for coarse-grained and fine-grained access control, respectively. Using HTTPS for all API traffic — even internally — will minimise security risks. JWT validation, standardised across the system instead of differentiated across various endpoints, is also recommended. Key management can be simplified using JSON Web Key Sets (JWKS).

Consider more basic, common-sense aspects of API security  too. One such security flaw might be different authentication methods (such as single- or multi-factor authentication) used for the same resources. Watch out for signs of potential API abuse — such as requests with unexpected headers — even if the system fails to log any overtly suspicious activity. You should also audit your APIs internally. This process may uncover security weaknesses in an API that was built to be internal but subsequently became public without the necessary additional checks required of public-facing services. If this sounds like a lot to go through, then it’s worth remembering that the time spent on securing APIs is nothing compared to the speed and scale at which they facilitate tangible business growth. When it comes to safeguarding customers’ personal information and adhering to GDPR laws, there is only one lesson to keep in mind: you can never be too careful.

By Travis Spencer, CEO, Curity

APIs form the web’s infrastructure; they create the business behind big business. A running app’s map interface, an online florist’s payment system, a recruitment firm’s group video call function — these are all examples of APIs, or Application Programming Interfaces, helping businesses meet customers’ needs. But as the rapid growth in cloud computing continues, it’s clear that APIs are front and center in driving digital transformation and business revenue and will remain so for years to come. To get a sense of the increasing importance of APIs in sectors like finance you need only consider Stripe, the digital payment firm valued at $95 billion earlier this year to become the US’s most valuable private enterprise, or Visa’s thwarted attempt to acquire Plaid, the nascent banking API, in 2020 for $5.3 billion. If the rise of SaaS made businesses realise that their IT systems didn’t need to be proprietary, then APIs have supercharged the move away from in-house software solutions.

The benefits of API for future-facing financial organisations are obvious. APIs allow legacy banks and digital upstarts alike to offer customers a responsive, fit-for-purpose online service. Software developers can use APIs to innovate at speed in a user-centric way. The rich streams of user data that APIs can yield will only further enhance those goals, creating a virtuous circle. For firms that take insufficient care with API security, however, these rewards are loaded with risks. While APIs present ample opportunity for growth, fintech organisations have a special responsibility to ensure the safety of API-enabled transactions. They must ensure  that data breaches aren’t made easier by the presence of APIs in an app’s software architecture. We can only do that with banking-grade infrastructure that adheres to best security practices.

GDPR and the impact on the API economy

Before exploring this, it’s important to note the impact of GDPR. Since its introduction in 2018, organisations have had to overhaul their approach to handling personal information. (The UK currently operates under the same framework for now.) The immediately obvious impact on financial companies has been the threat of severe penalties for regulatory breaches Though such firms are far from the worst offenders, two Spanish banks were fined a total of $11.5 million in December 2020 and January 2021 for breaking GDPR rules. Those rules also cover obtaining explicit consent from customers (which is why you see pop-ups on websites asking for your permission to use cookies) and the so-called ‘right to be forgotten’.This right means that firms can no longer store your data in perpetuity without a good reason.

The GDPR rule most salient to the API economy, however, may be the one governing vendor management. This grants the user the right to control  how personal information circulates through IT systems. Personal data is  increasingly streaming out of GDPR-controlled organizations  through APIs. Without firm guardrails, such systems expose organizations to risk. Weak spots might include broken object level authorization which means the system cannot properly confirm a user’s access privileges. Another issue  is broken user authentication, a situation in which bad actors impersonate users with the required authorisation. Unprotected APIs are also vulnerable to Denial of Service (DoS) attacks. Granting administrators too many rights (i.e., mass assignment) can lead to exploitation if those accounts fall into the wrong hands. Security misconfiguration, code injections, improper assets management and insufficient logging and monitoring are other key API pain points identified by the Open Web Application Security Project (OWASP).

The list of dangers is long, but the good news is that banking-grade solutions for such API security problems already exist. These are built around OAuth which is an open standard for access delegation and is leveraged as a means for users to grant websites or mobile applications access to their information without sharing passwords. On top of this standard, financial-caliber APIs utilize OpenID Connect. This is an identity layer that allows applications to verify the end-user identity based on authentication performed by an Identity Provider (IdP or authorisation server). The identity and API access tokens issued by this IdP include “scopes” and “claims” that allow IT systems and APIs to precisely control the degree and nature of access to personal information. This prevents many of the security weaknesses mentioned earlier as well as other common API flaws. (In organisations with complex hierarchies, the improper assignment of permissions among different user groups can be avoided using scopes and claims as defined in the  OAuth and OpenID Connect.) The usefulness of these standards in addressing GDPR-compliance issues and API security challenges, more broadly, can be boiled down to three techniques:

1. The acquisition of explicit consent;
2. Utilization of Pairwise Pseudonymous Identifier (PPID); and
3. Phantom Tokens.

A PPID is an unguessable user ID with no overt association with the details of the actual user. Phantom tokens are tokens that are only accessible within a private network. They are typically mediated from an opaque, handle-token by an API or ZTNA gateway. This brokerage converts the reference to the actual identity data into a full-blown token that back-end APIs can use to perform authorization without exposing the sensitive user data within it beyond the private network.

The implications of privacy regulations on the Open Banking space are undoubtedly good for consumers across the globe. Around the world, there are a number of privacy regulations in place such as Europe’s GDPR, including Australian Privacy Principles (APP), Brazil’s LGPD and South Korea’s PIPA.

The regulations have forced fintechs to take data privacy far more seriously. This  has seeded serious investments in API cyber security and a much wider discussion on the importance of explicit consent in Open Banking. Improved API security instils confidence in customers that regulation-compliant firms will handle their data with care and seek explicit consent from customers in all situations. This, in turn, is more likely to cultivate customer loyalty. Allegiance is a precious commodity in Open Banking, since customers, faced with more choice than ever, will feel more empowered to be picky and switch banks in the digital era. It may seem that these regulations are designed to make life harder for banks, but that’s not necessarily the case. The regulations, for instance, streamline the framework in which banks operate by standardising security protocols on a global level. This makes compliance much easier for financial institutions.

Organisations will have to treat GDPR as a challenge to be met rather than a burden to be shouldered. Non-compliant firms can be fined either €20 million or 4% of global annual turnover. This should be motivation enough. Being on the right side of GDPR isn’t cheap either. The cost of compliance for UK FTSE 100 banks, as a recent report by Statista outlines, is more than triple that of the next closest sector (nearly €80 million). Whether a bank decides to hire a GDPR specialist or outsource that work to a third party, an organisation that successfully navigates the GDPR maze will need to show a commitment beyond the bare minimum. This will require on-going risk assessments, stress testing, properly trained staff, and deploying up-to-date technology.

Consider the common-sense element

Where the API economy is concerned, following the right strategies will help companies get the most out of its rewards while minimising the risks. Installing an API gateway will centralise traffic features, enabling better control of requests that affect both security and business concerns. A dedicated OAuth server that issues tokens is more secure than tokens issued at multiple points across the system. Combining opaque tokens with JSON Web Tokens (JWTs) will optimise safety and convenience if your system is communicating with both internal and third-party clients. Scopes and claims can allow for coarse-grained and fine-grained access control, respectively. Using HTTPS for all API traffic — even internally — will minimise security risks. JWT validation, standardised across the system instead of differentiated across various endpoints, is also recommended. Key management can be simplified using JSON Web Key Sets (JWKS).

Consider more basic, common-sense aspects of API security  too. One such security flaw might be different authentication methods (such as single- or multi-factor authentication) used for the same resources. Watch out for signs of potential API abuse — such as requests with unexpected headers — even if the system fails to log any overtly suspicious activity. You should also audit your APIs internally. This process may uncover security weaknesses in an API that was built to be internal but subsequently became public without the necessary additional checks required of public-facing services. If this sounds like a lot to go through, then it’s worth remembering that the time spent on securing APIs is nothing compared to the speed and scale at which they facilitate tangible business growth. When it comes to safeguarding customers’ personal information and adhering to GDPR laws, there is only one lesson to keep in mind: you can never be too careful.