It’s an unfortunate reality that if a system faces the publicly-served internet, chances are it will be attacked at some point within its lifecycle. This is simply a matter of statistics — given the number of users utilizing APIs, the Internet of Things, and the dynamic World Wide Web, an attack is statistically more likely than unlikely. According to a report from The Hill, cyber-attacks increased 48% during 2014.

Despite this grim reality, API providers often consider security to be “someone else’s problem”. Weak points in an API construct can expose customer data, backend server appliances, and even monetary systems to unauthorized access, putting your API (and more often than not, your business) at risk.

So what should one look out for to avoid an attack? In this post we present four top security risks and concerns that every API provider needs to consider — along with how to mitigate them.

Gauging Vulnerabilities

Before we can truly appreciate the errors most commonly committed by API developers, we need to understand what constitutes a vulnerability and how they are measured.

When identifying vulnerabilities, an API provider or developer should ask themselves, “does this expose something that shouldn’t be exposed?” It can be a simple, small exposure, such as allowing someone to access the root file path on a server, or something as complex as failing to plan for complex denial of service methods that utilize exposed resources to deny authentication services to legitimate users.

We’ve discussed this before — in our piece, The 4 Defenses of the API Stronghold, we used armor as a metaphor for the types of licenses inherent in the API system. This metaphor holds true for vulnerabilities as well — while you might have a wonderful suit of steel armor, replete with plates, spines, and reinforcing braces, if you lack a simple Gorget, a series of plates protecting the throat, you would be vulnerable to defeat with a single blow. An entire system can only be considered as secure as its weakest part.

Identifying Vulnerabilities: Black Hat vs. White Hat Hackers

Not all possible “exploits” are identified internally. There are a great deal of hackers throughout the World Wide Web who try to gain access to a service, but do so not for the purpose of malicious use.

In the hacking world, there are two categories into which the majority of hackers can be broadly categorized — Black Hats and White Hats.

The Black Hat hacker is most commonly discussed within the security community, and are thus part of the public consciousness. When people think of hackers, they are usually thinking of Black Hats — hackers typing away at a server console screen, attempting to illicitly bypass security measures for personal gain or enjoyment.

These dangerous hackers may immediately utilize an exploit — many Black Hats will find an exploit, and bide their time until either authorization or authentication roadblocks can be similarly bypassed or a zero day exploit embedded in the system is utilized.

Of more use to API developers, however, is the White Hat hacker. These hackers utilize the same tools and techniques as Black Hats, but for a wildly different purpose — to increase security. These hackers, often hired by companies to test security, identify exploits and vulnerabilities for the sole purpose of reporting them to the API provider and/or public in the hopes that they may be patched before they are illicitly used.

Do not underestimate the value of hiring outside members to commit penetration testing on your API. To quote an old turn of phrase, “you can’t see the forest from the trees”. Outside security testing can help identify vulnerabilities, and rectify them before they become full-on exposures.

Risk 1 – Security Relies on the Developer

Many feel that security is as much the responsibility of the developer consumer as it is a responsibility of the API provider. In some cases, this is true due to the nature of APIs — authentication exchanges, physical access, and so forth should be partially secured by the one who is requesting usage, especially in the case of B2B or Public APIs.

However, as security is best implemented at the lowest possible level, it should be the problem of the API developer (the API provider), and the API developer alone. All other security solutions should spread from the base of the API developer’s approach and guidance, and not the other way around.

The philosophy of fostering an internal culture of security encompassess a wide variety of solutions and responsibilities. Developer-centric security means correctly overseeing versioning and dependencies, and properly handling authentication and authorization along with delegation and federation — a huge issue within the API space, as improper authorization and authentication policies can lead to massive security breaches through the exposure of administrator or sysop credentials. Improper session handling and failure to properly verify delegation and federation routines can lead to session capture and replay attacks.

The API developer consumer and end user can not help with any of these in a meaningful way. Utilizing HTTPS, SSL, SSH, and so forth is helpful, but cannot be done without the API host first designing the system to utilize these solutions.

Also of consideration is the fact that there is a stark difference between API Developers and API Providers. An API Provider is the single body or group of bodies that creates the initial API; an API Developer is a developer who ties into this API, extends upon it, or otherwise implements it in a service. Security, in this case, is easiest to implement within the scope of the Provider, and should thus be the approach taken when an API is in its infancy.

The takeaway – Secure Your System – It’s YOUR System!

Risk 2 – “Just Enough” Coding

Perhaps the biggest vulnerability is one that originates earliest in the API development lifecycle — improper coding. Regardless of language of choice, poor error handling, value checking, memory overflow prevention, and more can lead not only to massive vulnerability issues, but to fundamental issues of usefulness and functionality. One phrase that sums up this style of coding is “Just Enough” — the code in question is just enough for functionality, or just enough for usability, without the greater concern of how the code ties into the platform as a whole, what security concerns are addressed or not addressed, and how potential threats are handled.

The easiest way to present this is to show some basic code snippets that, despite their usefulness to the API functionality, expose the API in some pretty significant ways.

First, let’s use an example of an image sharing API written in Python. This API uploads images to a specific root of a specific server for sharing amongst friends utilizing an automatically generated URL system:

from django.core.files.storage import default_storage
from django.core.files.base import File
...
def handle_upload(request):
 files = request.FILES
 for f in files.values():
   path = default_storage.save('upload/', File(f))
…

This is a working service — but upon inspection, it fails several important security checks. Firstly, there is no type checking; a file of any type can be uploaded, meaning that anybody can upload an executable and utilize the automatically generated URL to run the application natively on the server. Secondly, the path for the uploaded file is specified to the service directory root, meaning that the application will have broad level access to the server.

Let’s look at another snippet. This example will be an error report generated from improper command usage in COBOL:

...
EXEC SQL
 WHENEVER SQLERROR
 PERFORM DEBUG-ERR
SQL-EXEC.
...
DEBUG-ERR.
 DISPLAY "Error code is: " SQLCODE.
 DISPLAY "Error message is: " SQLERRMC.
...

While error handling and notification is vitally important, the way this is handled above is flawed. When a Black Hat attempts to utilize a malformed command, they will instantly know two things:

• If the error is served via console (the default behavior of many servers), the connection to the service, despite being malformed, will be kept open.
• Secondly, that the server is vulnerable to SQL injection. This type of error is known as an external system information leak.

These may seem trivial to an outsider, but to a hacker, this is a treasure-trove of information. Imagine being a burglar who, through a simple phone call, and find out which door is unlocked, which window improperly seated, where everyone is sleeping, and where the valuables are. The information gleaned above is tantamount to this wealth of information, and serves the hacker a tremendous benefit.

These types of errors are grave, indeed — simply understanding how your code functions and how the average user will utilize system functionality can go a long way towards securing these vulnerabilities and not exposing system details.

Risk 3 – Misunderstanding Your Ecosystem

The API world is a rapidly shifting place. As API architectures evolve, and new, more expansive methodologies for microservice development and management emerge, the security issues inherent with each choice in the API lifecycle naturally evolve alongside.

Unfortunately, many developers seem to adopt these new technologies without fully understanding what they mean for API security. It’s so easy to adopt the “brightest and best”, but without a similarly evolved development mindset, vulnerabilities can quickly become far larger than they have any right to be.

For example, the innovations in cloud computing, especially in terms of the evolution of Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service platforms, has led to a massive amount of data and computing being handled off-site. What was once an environment of local resources and servers utilizing an API to communicate with the outside world is becoming increasingly decentralized.

While this is a good thing, it comes with some pretty heavy caveats and vulnerabilities. For example, utilizing side-channel timing information, a virtual server sharing the same physical space as that of an API virtual server could theoretically hijack private cryptographic keys, according to a research paper from the University of North Carolina.

Barring such virtual attacks, there is still the issue of physical threats. Because a cloud server is not local to the API developer, physical security cannot be maintained, meaning hardware hosting secure password hashes or user account files can be vulnerable to environmental damage or malicious use.

Much of this can be negated. Proper server file security, backups, and more can go a long way towards improving security vulnerabilities of this type. But these solutions can only be implemented if the issues are known — and for many API developers who have moved legacy or classically designed APIs to the cloud space without first understanding the ecosystem, this is easier said than done.

Risk 4 – Trusting the API Consumer With Too Much Control

While much has been said about maintaining positive user experience through the API lifecycle, average end-users are the number one largest security risk an API can ever have.

Regardless of the API type, language and syntax, or development approach, an API is functionally secure until it’s actually used.

Until your API receives its first request for information, it lives in a veritable island of security — isolated, alone, but ultimately untouchable. The second it receives that request, however, it’s wide open. When developing an API, developers often trust the user far too much, allowing too much data manipulation, not limiting password complexity and usage, and sometimes even allowing repeat session ID tokens. This is a huge issue.

That’s not to say you should treat every user like a Black Hat — most users are going to be legitimate, are going to use the service how it was intended, and will not be a security vulnerability in and of themselves. But, assuming that most of your users are “good” users, that still leaves a good deal of “unknowns” who can use anything gleaned through average use to break your system and access it illicitly.

Thus, you must assume every user is a vulnerability. Implement password strength requirements, session length and concurrent connection limitations, and even require periodic re-authentication and authorization for continued use. Track usage and account metrics, and respond to any deviation. Assume that even your best user is subject to hijacking and malicious redirection, and plan accordingly.

Conclusion: Securing the API Stronghold

By understanding these basic security risks and adequately responding, API security risks can be largely mitigated. While no system is ever going to be truly perfect, they can at least be complex enough and complete enough to deter all but the most ardent and dedicated hackers.

If you’re into API security, we’re preparing for an upcoming security-themed eBook – Securing the API Stronghold. Track our progress here, and signup to our newsletter to be notified when it’s released!