Runscope API Monitoring    Learn More →

Best Practices for API Security: Avoiding Common Security Vulnerabilities

By Scott Fitzpatrick on .


Scott Fitzpatrick is a guest contributor for the Runscope blog. If you're interested in sharing your knowledge with our readers, we would love to have you! Please fill out this short form and we'll get in touch with you.

It’s fairly easy to see that API security can be of the utmost importance when designing and implementing an interface that might be used by another entity over which you have no control. By allowing another organization to interact with your application directly, you are putting your data at risk.

Taking the appropriate security measures throughout the design process can ensure that your API is used properly by those you allow to interact with your application. Such measures include the utilization of an effective strategy to authenticate the application employing your API, taking steps to ensure that the client application is authorized to perform the actions they are attempting through your API, and bulletproofing against common API vulnerabilities such as XSS and SQL injection.

In this article, we’ll take a look at API security best practices and discuss strategies for securing APIs.

Properly Authenticating and Authorizing Client Applications

The first thing to understand is that authentication and authorization are two terms that mean very different things in the context of API security. Authentication means determining that the client application has an identity that is allowed to use the API. Authorization is determining the scope of interaction allowed by the API for the authenticated application—that is, what actions and data the authenticated application has access to when using the API. Authentication is the first layer of security for your API, while authorization is a subsequent and very important counterpart.

So what approach can you take to handle the issue of authentication and authorization that will assist in securing your API? OAuth 2.0 can assist in satisfying your needs as an API developer in terms of authorization (and possibly authentication) when used in a particular manner.

OAuth 2.0 can have four players in the scenario in which a client application is allowed access to your API. These four players are a Resource Owner, a Client, a Resource Server and an Authorization Server. The Resource Owner is essentially the user who is attempting to utilize the Client (client application) to access your API (Resource Server). The job of the Authorization Server is to provide the Client with an Access Token which the Client can then use to access the Resource Server.

OAuth 2.0 provides a variety of benefits from a security perspective. For one, the authorization process ensures that the requests to your API are being made by a registered client—You know who is attempting to access your data. In addition, the Access Token lends itself to easily retrieving the identity of those accessing your API, and the quick expiration of the Access Token (typically in a matter of hours) ensures that the client application will be vetted again as to whether or not they are allowed to access the service.

Think about it this way—With the short lifetime of the Access Token, your API service is given the ability to revoke access from a particular client application when necessary. In such a case, when the token does expire, the client application will be denied access when they try to again gain access to your API. In addition, using OAuth 2.0, you can limit the scope of access to your API depending on the identity of the Client accessing your API. In this way, the Client and Resource Owner are only able to retrieve information they are allowed to see.

You can also check out Keith Casey's post on "Understanding OAuth 2.0 and OpenID Connect" for a more in-depth look into OAuth 2.0 concepts and resources.

Protecting your API: Preventing XSS and SQL Injection in Your API

Aside from properly authenticating and authorizing users of your API, it is crucial that the API itself is developed with safeguards in place to prevent malicious use when clients make API calls. Common (yet avoidable) pitfalls include leaving your API open to attacks in the form of XSS and SQL Injection. It is on the API developer to ensure that the API properly validates all input from the user made during any calls to prevent this from occurring. Ways to protect against these types of vulnerabilities include cleaning user input to prevent XSS, as well as applying as many tips as possible to prevent SQL Injection from OWASP.

One of the most effective ways to safeguard yourself against SQL Injection attacks is to utilize prepared statements with bind variables.  Chances are the language you are using to write your API will contain functionality that you can use to assist in this effort. See below for a simple example in Java that leverages PreparedStatement and bind variables to protect against SQL Injection attacks.

PreparedStatement statement = connection.prepareStatement(“select first_name, last_name from customers where customer_id = ?);
statement.setString(1, customerId);

By utilizing bind variables rather than using string concatenation to provide the query with the customerId variable you are employing a much safer practice for pulling information from your database.  Combine this with some additional validation of the variable represented by customerId and you are well on your way to an application that is much less vulnerable to SQL Injection attacks.

Cross-site scripting (XSS) is when JavaScript code is sent as input. If the input was then rendered by a browser, the JavaScript code would be executed. This represents another challenge when it comes to securing your API and can be dealt with in large part by cleaning the user input sent when the API call was made. Stripping the input of HTML and JavaScript tags is the first step to mitigating potential XSS vulnerabilities. In doing so, you will take a big step toward ensuring that the user can’t pass JavaScript code to your method that will then be rendered and executed. See the very simple example below as to how a user may try to expose an XSS vulnerability. The user may pass, as input, something similar to the following in the API request:

<script> {user evil scripting goes here} </script>

But by validating and cleaning input in a manner that does not allow JavaScript tags you will strip the <script> tags from the above code leaving just the text.  Thus taking away any power it may have had as executable code. This may not be a vulnerability your API has but if user input is rendered as output in a browser through the use of your API then it is important to validate all input and sanitize the output.

Throttling your API

Concerning APIs, throttling is a means of controlling or limiting a client’s access to your data.  This is important for security purposes as it allows you to identify irregularities related to client use of your API.  An API essentially allows client applications to access valuable data that you hold and controlling that access is another way to provide that data with an extra layer of security.

Below are a few types of API throttles that will provide you with additional control over how your API is utilized:

  • IP-based throttling – This type of throttling can be used in multiple ways to help protect your data. Through the use of IP-based throttling you can restrict the number of API calls made by a particular IP address. In addition you could ensure that your API can only be accessed by a particular set of IP addresses. If this is a feasible option for your particular API this would help by providing another layer of security in the effort to prevent unauthorized access to your data.

  • Rate-limit throttling – Rate-limit throttling allows API requests to be made until a certain limit has been reached for a specific time period. This throttle represents a temporary condition where the requests will no longer be processed and (oftentimes) an exception will be thrown. By utilizing rate-limit throttling within your API you can help to ensure that the database isn’t overwhelmed by one particular client who may be misusing your interface.


Effective API security can rely heavily on one major factor: proper implementation of a secure system for authentication and authorization. This is especially vital as it can mean the difference between your data staying safely and securely in the hands of those who should have access to it and it being widely available to nearly anyone, whether a valid client of the API or not.

In this article, we’ve covered three best practices that can help to improve API security: Using OAuth 2.0, mitigating the risk of injection attacks and API throttling. There are other types of security vulnerabilities that you should consider when designing and implementing an API too (and open-source projects that can help you test those), such as buffer overflow attacks that target an API or cross-domain resources that are not properly vetted. But we’ll save those discussions for a future article.

At the end of the day, the single most important thing you can do to keep your APIs secure is to treat API security as a priority. You want to factor security into every step of the process when you create and API, and you want to include API security monitoring as part of your deployment strategy.

Categories: apis, security

Everything is going to be 200 OK®