What is now commonly called APIs or Application Programming Interfacesbrings together a set of inter-application communication methods ranging from web services (REST or SOAP) to local or remote inter-process (RPC) calls. Although APIs have spread like wildfire in recent years and represent a predominant and essential communication mechanism for all companies launched in their digital transformation.
They are now met in an ever-increasing number of important use cases: public, personal or sensitive data, applications, mobiles, exchanges between partners, IoT, so-called "client-side" applications, etc.
The concept is not new. From the introduction and definition of the idea of architecture REST, in 2000, the first APIs were born. First, the pioneers were eBay in particular or Flickr, then Facebook and Twitter have made it the heart of their product on which third-party developers could come and build their services. And from the birth of this concept raised the question of securing access to this new type of web service.
Experience shows that securing APIs is a recipe based on four ingredients that must be carefully dosed. Several security measures and good development practices are available to developers and operations teams to cover the traditionally targeted risk areas by an attacker:
The attack surface expands with APIs becoming a fundamental part of modern application development. Gartner estimates that by 2022, fraudulent use of APIs will be "the most common attack vector and lead to data breaches in corporate web applications."
The downside of public web APIs is that they come with risks. By design, they allow outsiders to access data. Behind each API hides an endpoint, namely the server (and its databases), which response to requests.
Endpoints are similar to web servers connected to the Internet and carry the same risks. The difference is that many websites generally employ some form of access control, much less so with APIs.
In the worst-case scenario, it's not just the data that is at risk, but the infrastructure as well. Vulnerable APIs are the ideal starting point for various network hijacking attacks. A practical (most often multi-level) attack can potentially compromise sensitive data, whether it is personal identifying information or intellectual property.
In addition to the risk mitigation measures described above, adopting some basic security practices, and enforcing well-established security controls, are critical if organizations plan to share their APIs publicly. The following principles must be emphasized in particular:
Safety: API security is a priority to integrate into APIs during their development.
Maintain API inventory: The company must conduct perimeter analyses to identify and inventory its APIs and then organize them with DevOps teams.
Use strong authentication and authorization: The authentication process of APIs does not enforce authentication (as is often the case with private APIs, exclusively for internal use).
Knowing that APIs provide a point of entry to corporate databases, the enterprise must strictly control its access. Where possible, solutions based on robust and proven authentication and authorization mechanisms such as OAuth 2.0 and OpenID Connect should be used.
Apply the principle of least privilege: A subject (user, process, program, system, device) should not be granted access rights more significant than those necessary to perform a given function.
Encrypt traffic using TLS: For companies with APIs that regularly exchange sensitive data (login credentials, social security numbers, credit card information, medical or banking information, etc.), TLS encryption is essential.
Delete information that is not intended to be shared: APIs are primarily designed for developers. This is why they often contain keys, passwords, and other information that must be removed before being made available to the public. However, this step is sometimes neglected. Companies should integrate analytical tools into their DevSecOps processes to limit accidental exposure of confidential information.
Do not expose more data than necessary: APIs should not return more information than required to perform their function. It is also essential to apply API-level data access controls, monitor the data, and obfuscate confidential information contained in the response.
Validate the input data: Input data should never be passed from APIs to endpoints without prior validation.
Limit traffic: Setting a threshold beyond which requests will be rejected (for instance, 10K requests per day per account) can prevent denial of service attacks.
APIs were quickly established as the preferred method of building applications, mobile devices, and the Internet of Things (IoT). However, in the face of continuously evolving, changing application development methods and pressures for innovation, some users have not fully utilized the potential risks of making their APIs publicly available.
The best aspect is that most of them have measures to combat cyber-attacks; For instance, Cross-Site Scripting, Injection, and Distributed Denial of Service. Start from the top of the list and work your way down in doubt. Regardless of how many APIs have been shared publicly, an organization should never lose sight of putting strong security policies upfront and managing them proactively over time.