The Accidental API
How your web or mobile API might be putting your business at risk
Do you have a web or mobile API? You might, whether you realize it or not. Web APIs are often used to connect a modern web application to the backend database using JavaScript frameworks such as Backbone, Angular, or Ember. Web APIs are also used by mobile applications to enable collaboration between devices, along with remote data access. So, chances are that your development team has built a web or mobile API – even if you didn’t know they did.
(Not familiar with web or mobile APIs? No problem. Read our gentle introduction to APIs here)
What is an Accidental API?
If you do have a web or mobile API, you need to find out if it was an accidental API or an API product. Accidental APIs are ones that are built quickly to solve the technical problem, deployed into production, but do not consider the business needs or possible risks associated with a production API.
API products, however, are often governed, managed, and monitored as part of an overall strategy and are often treated as separate products with their own software development life cycle (SDLC). While some API products may be open for public developers to use, many are simply used internally or limited to partner integration. Either way, these APIs are treated as separate products within the organization and often have their own associated team, KPIs, and associated ROIs.
So, do you have an accidental API? If so, the next question you ask should be, “What are the risks of having an accidental API to the business and how can we avoid them?”
Let’s look at five common risks encountered as a result of having an Accidental API, and how to mitigate them:
Risk #1: Added Maintenance Costs
Accidental APIs are often developed in a hurry, many times with little or no time spent to ensure that they have been designed to last. Issues often encountered as a result include:
Bad design: This results in slower development, hard-to-understand design, cryptic error messages (or none at all), and longer development time when debugging integration with mobile or web applications
Versioning issues: Lack of thoughtful design requires versioning an API, which will require dedicated time from mobile developers to fix and push one or more updates to mobile applications. This often requires maintaining multiple versions of the API for a longer period of time, costing the company 2-5x that of a well-designed product API
Lack of business value: Accidental APIs aren’t designed to deliver complete business value. Partner APIs will likely result in multiple, one-off partner or platform APIs for successful integration
How to mitigate this risk: Invest in a proper API design by applying practical design principles that will deliver high business value, reduce costs, and encourage reuse (increasing agility).
Risk #2: Uncontrolled Public Access
Did you know that private, hidden APIs aren’t really hidden? Any developer can often reverse-engineer APIs used by web and mobile applications to understand how they work. Then they can simply use them for their own purpose, often unbeknownst to your business. When this happens, you:
Lack ability to revoke access: Since Accidental APIs often don’t require authentication tokens (or use shared tokens), there is no way to shutdown access for a specific application without disrupting all other web and mobile applications. Mobile apps will likely need to be updated to use a new key, and it may take some time before all installed versions are updated, causing downtime and loss of revenue.
Lack control to limit data/application usage: In addition, lack of proper authentication mechanisms allow developers to easily access any/all available data without restriction. Your valuable data is then exposed, without limitation, to anyone and without proper logging and auditing.
How to mitigate this risk: Implement API security to restrict access to the API, using standards such as OAuth.
Risk #3: Inability to Monitor, Monetize, and Scale
Accidental APIs lack monitoring capabilities, preventing any insight from who, and how, an API is used.
Lack of Usage Metrics/Insight: Lack of insight into what partners/applications are using the API, how they are using it, and where revenue opportunities may exist. This is most important for integration partners, as contract renewals may allow for an increase in revenue for partners that more heavily depend upon the API.
Inability to communicate changes: APIs will change and without monitoring, you will have no idea which partners, internal departments, or integration partners use a particular part of the API that is being changed.
Inability to Scale: Lack of proper management prevent the ability to monitor and scale APIs. Often, APIs are co-deployed with other applications, which may limit the ability to easily deploy and scale quickly. This lack of rate limiting can overwhelm servers and reduce the performance of your application, or even render it unavailable.
How to mitigate this risk: Select and install API management middleware. Popular vendors today include: 3scale, Apigee, and Mashery.
Risk #4: Lack of Security
Until now, we have focused on risks that are related more to the business and daily operations. Now we enter the last two risks, where we see a more severe impact. These risks can not only affect business operations, they can also affect the longevity of the business and your customers. Accidental APIs open up a variety of security-related issues, including:
Lack of secure communications: Accidental APIs may be deployed without SSL, either if the primary application doesn’t require it or if the API is deployed haphazardly. This means that logins, passwords, and other sensitive data are sent in plain text and easily obtained.
Industry or business compliance failures: Lack of proper security precautions can often expose holes in the company’s PCI compliance, or other industry regulations.
How to mitigate this risk: Conduct a security audit of the API, implement the appropriate measures, and ensure SSL is implemented across all API communication channels. You may wish to also consider an API management layer that implements authentication standards such as OAuth and performs data masking to protect sensitive data.
Risk #5: Malicious API Attacks and Compromised Data
The final risk is related to API attack vectors with the intent of compromising the system and its data. Accidental APIs tend to expose systems to the following vulnerabilities:
Denial of Service (DoS) attacks: Attackers can try to reduce or completely eliminate the system’s ability to service incoming calls by overwhelming the system with API calls, rendering the system unusable by internal, partner, and potentially public consumers of the API.
SQL injection attacks: SQL injection is a technique uses to try to access or modify data by attempting to alter SQL statements executed by the API endpoints, exposing data that was previously not available.
XML attacks: An XML attack is designed to compromise servers by sending large, invalid, or malformed XML content. Servers are often made unavailable due to memory leaks or high CPU usage when trying to process large or malformed content.
Lack of data masking: Data masking is the technique of transforming, encrypting, or removing sensitive data transmitted by an API. Accidental APIs often take little or no effort to hide the data, often times implementing a ‘SELECT *’ from the database. The result is that sensitive data and internal data useful for other attacks is made available.
How to mitigate this risk: Conduct an operations audit of the API environment, a code review to prevent various attack vectors, and a thorough review of all data sent and received by the API.
How To Move From An Accidental API to an API Product
As you now realize, APIs can be a powerful tool for web and mobile applications for your business. However, they need to be treated with the same review and implementation strategies that your other products require. We recommend performing an internal review, seeking outside assistance if necessary. Not only will this help you reduce your security risks, it will result in a reusable API product that will produce business value.