In a hyper-connected world, one breach of the API eco-system could spell disaster
APIs are a hugely popular approach to integrating applications into web interfaces, and their use has skyrocketed over the past 5 years. They provide the building blocks for various programming tasks, and developers depend on them – ProgrammableWeb lists over 17,400 APIs available for developers to use.
And they may be making end users vulnerable.
As ProgrammableWeb Editor in Chief David Berlind has stated:
APIs are rapidly becoming one of the most important infrastructural layers of the Internet while at the same time becoming a critical component of modern day attacks. They are difficult to secure and determined hackers are extremely tenacious in finding ways to exploit them.
Despite what some people — even experts — would lead you to believe, there are no silver bullets. That said, when proactively managed and secured, the efficacy of APIs greatly outweighs the risks associated with deploying them.
There is currently no standard third-party certification system to indicate trusted API developers, which Berlind has called for. He also says that the actual adherence to security standards by the developers of APIs lags behind the establishment of these standards.
A further pitfall exists, as Berlind notes: when a company with a trusted name launches an API, users generally believe that they can rely upon the API’s security. But that’s not always true. Google, Apple, Facebook, Pinterest, Snapchat, Verizon, and other major companies — which we might assume have plenty of resources to devote to ensuring security — have experienced API security breaches.
So, who’s at fault here?
Berlind blames human error for all these cases. And malicious hackers are ingenious, sophisticated, persistent, and elusive — meaning more vulnerabilities are likely to come, exposing developers and users to the risk that secret data will be shared with people it’s not intended for.
But where do we start with API security? In a 2014 PowerPoint presentation, Cadence Design Systems VP Tim Mather started with this question: “Do you even know what APIs your organization has or is using? Do you even know what data is being shared via APIs with your trusted and untrusted customers, partners, and/or vendors?”
Blogger Paul Korzeniowski wrote a post for TechBeacon.com suggesting eight best practices. He suggests that users begin by recognizing that malicious hackers may target their code, and accepting that that risk needs to be addressed. His further recommendations include:
- Monitor add-on software carefully — bad guys often try to exploit the high-level permissions granted to add-ons
- Focus on authorization and authentication on the front end — meaning, users should be subject to a multi-step process to ensure they have a right to view the resource they’re requesting
- Remember to check data on the back end — meaning, even if an attacker gains access, make it impossible to transport that data out of the system
- Consider using API security tools and gateways
- Budget time for security testing — rushing this critical step may leave holes undetected and users vulnerable
Berlind suggests further steps, in a more macro look at the topic. But as with any technology, he notes, API security improvements may come with a trade-off in reduced convenience.
So, what can be done?
Smart companies are recognizing that it’s possible that a flaw will get through, and are enlisting the help of the white hats. Google has paid bounties to people who identify security holes. Facebook has also given incentives to users who flag API vulnerabilities. Berlind endorses this approach of collaboration the white hats in efforts to enhance system security.
And, those smart companies make sure that their API integrators spend significant time testing the security of their code, that their staff has the know-how and resources to properly do that job, and that the public has good reason to help them out if — or when — the an unexpected vulnerability rears its head post-release.