Attacks that exploit application programming interfaces (APIs) are on the rise, resulting not just in stolen data, but compromised systems and even attacks on accounts, experts say. APIs are commonly used to connect banking applications to fintech and data services.

A number of high-profile attacks recently have leveraged API vulnerabilities, Roey Eliyahu, CEO and co-founder of the API-security firm Salt Security, told Bank Automation News. Eliyahu pointed to the April Experian data breach, in which an API exploit in a partner’s website could have potentially exposed the credit scores of millions.

“Unfortunately, APIs are very vulnerable,” Eliyahu said. “There is not enough awareness in the space. Companies are not realizing how vulnerable they are.”

Salt Security on July 14 released the results of a vulnerability report in which it determined an unnamed U.S. financial institution had numerous API weaknesses that could be exploited. Not only did the API security firm find data could be stolen, but it also discovered accounts could have been deleted by an attacker.

A “shocking number of API endpoints” are left open without requiring authorization, said Sander Vinger, a threat researcher with the technology security firm f5. That is a basic requirement, as a bank or financial institution would never allow individuals to log into their website without some form of authentication, he pointed out.

“If you are a developer, who always thinks about the legitimate users doing the right thing, you’re going to assume, ‘Well, this is made for machine consumption. So nobody is ever going to authenticate to this system,’” Vinger told BAN. “And that’s kind of where the mistake happens, right? Because attackers are big to go under the hood; as a matter of course, that’s how they work.”

Accessing external APIs

Increasingly, organizations are concerned about the security of the APIs they consume. Sixty-six percent of 200 survey respondents — which included a range of IT workers, 60% of whom were in technology and financial services companies — said they have delayed the deployment of a new application because of API security concerns, according to a Salt Security study released earlier this year.

One way that financial institutions and fintechs can determine risk is by enlisting a third party that specializes in API security to perform regular assessments of possible vulnerabilities, advised David Biesack, vice president of API platforms and lead API architect for the cloud-based digital banking fintech Apiture. It’s a practice he said Apiture has embraced.

Kendall Reese, the chief information security officer and senior vice president at the $23.3 billion Simmons Bank, based in Pine Buff, Ark., told BAN he often finds APIs from vendors and software-as-a-service providers are not created with security in mind.

To protect the bank, Reese’s team reviews security controls around APIs and assesses the level of risk an API might cause. The team considers the following:

• How strong is the key used to allow access to the API?
• Can the account used to access the API be limited to specific functions?
• Can the availability of the API be limited to Simmons Bank Systems?
• The bank also looks at certificates, tokens and the network whitelists to bolster security with APIs.

“Ultimately, Simmons Bank data is our responsibility wherever it is stored or utilized, and we try to limit the risk to our data,” Reese said.

Hardening APIs in development

Ideally, APIs should be “hardened” in the design process, Biesack said. This refers to making APIs more secure and closing vulnerabilities.

“Security must be a primary non-functional requirement, and the team’s API governance model should include risk assessment of all new API features,” Biesack told BAN. That means being familiar with the security measures that should be “deeply embedded in the software development life cycle, including security testing strategies,” Biesack added.

It’s also important to ensure authentication authorization is in place, Vinger said. While there are no standards around API at the moment, REST APIs, which adhere to the REST software architectural style, are more a philosophy than standard or protocol, Vinger advises developers to use:

• OAuth 2.0, an industry-standard protocol for authorization;
• OpenID Connect — an identity layer for on top of the OAuth 2.0 protocol — for URL routers and authentication; and
• JSON Web tokens for security tokens.

Another tactic is to host regular internal security hackathons, in which developers are challenged to think like hackers and try to exploit the APIs, Biesack said.