State of API Security

Judging by the OWASP list of top 10 security vulnerabilities and accompanying assessment, security continues to be a major issue with applications. This is especially true in the era of APIs, where companies are making their core assets and business processes available for others to integrate with, in the hope of becoming a crucial (and thus "monetizable") part of an ecosystem. 

The risk for intrusion attacks, data theft or just plain-old DoS attacks is evident. The risk might be small, but the consequences enormous. Consider the Playstation Network outage that exposed 77 million user accounts, or the more recent Twitter security breach that exposed more than 250,000 accounts.

What is API Security?

API Security is a vast field with many different meanings and definitions. Most commonly when talking about API security, we mean authentication and possibly encryption. But the term harbors a diverse array of concepts that all require different expertise and approaches when it comes to testing and quality:

  • Authentication : reliably identify end user
  • Authorization : give identified user access to correct resources/data 
  • Encryption : hide information from unauthorized access
  • Signatures : ensure information integrity
  • Vulnerabilities : preventing attacks and damage to consumers or providers

Let’s have a quick look at each of these in a little more detail and see how they apply to APIs.

Authentication and Authorization

Authentication and autorhization are commonly used together:

  • Authentication is used to reliably determine the identity of an end user
  • Authorization is used to determine what resources the identified user has access to

On the web, authentication is most often implemented via a dialog that prompts for username and password. For added security software certificates, hardware keys and external devices may be used. Once the user is authenticated, the system decides which resources or data to allow access to.

For APIs it is common to use some kind of access token, either obtained through an external process (e.g. when signing up for the API) or through a separate mechanism (e.g. OAuth). The token is passed with each request to an API and is validated by the API before processing the request. (Alternatively, the dialog method may be used).

Encryption and Signatures

Encryption is generally used to hide information from those not authorized to view it. On the Internet, often SSL is used to encrypt HTTP messages, sent and received either by web browsers or API clients. A limitation of SSL is that it only applies to the transport layer. Data that also needs protection in other layers require separate solutions.

Signatures are used to ensure that API requests or response have not been tampered with in transit. The message itself might be unencrypted, but must be protected against modification and arrive intact.

Encryption and Signatures are often used in conjunction; the signature could be encrypted to only allow certain parties to validate if a signature is valid - or the encrypted data could be signed to further ensure that data is neither seen or modified by unwanted parties.


The area of security vulnerabilities is a diverse field. There are many different attacks with different methods and targets. One way to categorize vulnerabilities is by target area:

  • Network / OS / Driver: issues in the operating system and network components (e.g. buffer overruns, flooding with sockets, DOS attacks)
  • Application layer: issues in the hosting application server and related services (e.g. message parsing, session hijacking or security misconfigurations)
  • API / component: functional issues in the actual API (e.g. injection attacks, sensitive data exposure, incomplete access control)

Best Practices for API Security Awareness

Compared to functionality and performance, security may get little attention in QA. Often the frameworks and components used are trusted to be “secure” and warrant no further assessment in this regard. A serious approach to security testing should include (but not necessarily be limited to):

  1. Requirements: Make security visible in requirements and backlog processes, on the samel level as performance, functionality, usability, et c.
  2. Knowledge: Invest in security know-how and testing among your developers and testers, so they understand common security breaches and how to guard against them.
  3. Prevention: Test and assess security early in your project and don’t leave it to some single individual at the end right before production.
  4. Monitoring: Continuously monitor your applications for security vulnerabilities using available tools or homegrown solutions – as you would performance and functionality, with focus how new components or changes can have unwanted side effects.
  5. Awareness: Make use of free tools and resources (like those available at OWASP) to get an overview of relevant vulnerabilities and how to make sure they do not affect you.