By John Paul Mueller
In some ways, the most valuable asset your organization owns is your data. Threats to that data have to be identified and, hopefully, eliminated so you don’t put that value at risk. This is why security testing is so important. Of all the components that comprise an application, Application Programming Interfaces (APIs) provide the easiest access point for a hacker who wants your data.
You use API security testing to ensure that the API is as safe as it can possibly be. If there is an error in an individual application, it affects just that application. However, when there is an error in an API, it affects every application that relies on that API. In short, a single error can cause problems across your entire organization, as well as any external organizations using your API.
Defining the Stakes
The stakes are quite high when it comes to APIs. Fail to find a bug and your organization may make the front page. However, the benefits are just as high. Using APIs can significantly reduce the time required to build new applications, the resulting applications will generally behave in a consistent manner, and you aren’t required to maintain the API code, which reduces costs. But ensuring its security can be a problem. Performing functional tests isn’t enough to find vulnerabilities—you must perform tests that actually simulate the kinds of attacks that an outsider might try. This means thinking like a bad guy in order to figure out the kinds of attacks that an outsider might try.
Most people don’t have the time or expertise to think of all the ways that people will intrude their application boundaries. In fact, it’s really tough to think like a bad guy unless you really are one. Fortunately, there are ways to think like a bad guy that don’t involve much more than reading the trade press to determine how other organizations have been hacked and then devise tests that mimic those scenarios.
In addition, it’s important to know which kinds of security problems to target and test for as part of your API. One of the most important sources of information is the Web Hacking Incident Database (WHID), which lists: SQL injection (18.87%), cross-site scripting (12.58%), denial of service (8.06%), predictable resource location (4.35%), unintentional information disclosure (4.35%), and brute force (4.03%) as the most probable types of security breach.
Using WHID lets you examine the specifics of most incidents by clicking one of the entries in the Quick Downloads section of the page. Using the Full WHID Data on Google Fusion Tables option is probably the fastest way to go. The statistics also tell you that keeping the bad guy at bay is the responsibility of everyone in the organization. Fortunately, you can rely on your developers to knock out the two highest contenders just by creating secure applications and fully testing them.
It’s essential to remember that creating secure software, testing it fully, and even performing mock attacks against it will only keep the average bad guy away. If someone is truly determined to break your security, they will. So, part of what you need to take away from this article is that the need for testing is constant, as is the need for vigilance. Looking for the break-in will let you repair problems before they become front page news.
Understanding How API Security Testing Works
The essential premise of API testing is simple, but its implementation can be hard. Here are the rules for API testing (simplified):
- For a given input, the API must provide the expected output
- Inputs must appear within a specific range for the most part, so values outside the range must be rejected
- Inputs of an incorrect type must be rejected
- Any input that is null (empty), when a null is unacceptable, must be rejected
- Inputs of an incorrect size must be rejected
Unfortunately, a lot of APIs aren’t tested to meet these criteria, which means that any API you use is a risky proposition. In short, to ensure your application behaves precisely as expected with the least risk potential to your data, you must test any API you use to ensure that the API is safe. APIs are designed as black boxes, so you don’t need to know how the API works, but simply need to know that the API behaves in the expected manner.
How Can a Lack of Security Testing Hurt?
It’s important to put API security testing into perspective. There is an incredible amount of hype that goes with some of the security breaches you read about. Keeping your goals in focus, implementing the best test procedures possible, and following best practices in monitoring your application will generally do everything needed.
The most important thing to consider is the actual data loss or data damage that can cause all sorts of problems for your organization. Recovering data is an expensive and error prone process that will cost more than time and money. It could cost you clientele or make it impossible for you to conduct business properly until all of the data errors are fixed. Always make sure you test every possible kind of input to your applications, but also make sure you have a backup plan in place for those times that things go wrong.
You have probably seen a number of high profile security breaches as of late, such as Snapchat. The fact of the matter is that Snapchat is still in business. However, the online site has taken a huge hit in reputation and has probably lost some of its audience. In short, as a public facing organization, you can ill afford the negative side-effects of API security issues. Make sure your organization is proactive in telling others what steps you take in securing their data.
Privacy is another concern. Theoretically, you could end up in jail for breaking privacy laws coupled to security breaches. The loss of customer confidence after a breach won’t do you any good either. Address any potential privacy issues immediately and perform remedial steps as needed. Of course, it’s always better to avoid the security breach in the first place.
In short, API security testing is an essential part of the application development process today. Given the number and type of recent security breaches, you can expect the public to take a dim view of anything less than your best.