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); statement.execute();
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:
But by validating and cleaning input in a manner that does not allow JavaScript tags you will strip the
