Serg Nvns - Fotolia
There are as many ways to prevent an API security breach as there are to hack APIs. Unfortunately, hackers can succeed by using just a few attack methods. Developers, however, have to adopt a broad set of practices to control API security, said Subra Kumaraswamy, chief security architect at API management systems provider Apigee, and co-author of Cloud Security and Privacy (from O'Reilly Media).
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Developers must build appropriate security controls -- such as rate limiting and security token management -- into an API management platform, said Kumaraswamy, a founding member of the Cloud Security Alliance. Rather than customizing the protection on a per-application basis, he recommends that developers using API gateways go one step further and support a global policy-based enforcement.
What is the status of the OAuth framework for building APIs? Is it still viable?
Subra Kumaraswamy: The OAuth [Open Authorization] framework is a very well-understood authorization framework for building secure APIs. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for Web applications, desktop applications, mobile apps and Internet of Things. However, keep in mind that OAuth is a delegated authorization protocol and not an authentication protocol. Hence, OpenID Connect, which is built over the OAuth standard, is an alternative for developers who want to programmatically verify the user identity in addition to authorizing the applications to access protected resources on behalf of users.
What are best practices for choosing and using an authentication method that allows login in the native app with the API knowing which user is sending requests?
Kumaraswamy: Developers should employ the three-legged flow of OAuth 2.0 when building native apps with end user authentication. In this model, upon successful user authentication, the native app obtains an access token -- short-lived -- and refresh token (long-lived) from an authorization server. The access token is presented to API services to access the protected resource, while the refresh token is used to renew access tokens. This approach provides lower friction with reduced sign-on and continuous user engagement with [the] mobile app. And developers can take comfort with the safety valve to revoke access and refresh [tokens] in an event the tokens are compromised.
What are common mistakes developers make in provisioning API keys? How can they avoid them?
Kumaraswamy: API keys are validated by the API gateway prior to providing access to protected resources. A common mistake is overprovisioning of keys with privileges that are not required for apps to perform certain operations against the APIs. For example, if you are exposing a payment verification API to a software developer, the API key should be limited to payment verification and should not be given privileges to modify the payment details.
Another mistake is giving unlimited access to APIs without imposing quotas per key. This can lead to a denial-of-service attack, as well as harvesting of data by automated bots. It is a standard practice to protect API key credentials with strong hashing – i.e, SHA-256 or higher -- and random salt.
What else should developers be aware of when building security into APIs?
Kumaraswamy: Developers should start with a threat model of the APIs to understand the threats based on the deployment models, such as internal APIs and external APIs. They must know the threats to API consumers, such as trusted developers, self-registered developers and partners, too. With that knowledge in hand, API designers and developers must build in the appropriate security measures to counter the threats.
Let's look, for example, at the threat model of APIs exposing sensitive data to an untrusted developer via the Internet. Here, the developer must [protect], usually via encryption, the sensitive data, both in transit -- ([Tranport Layer Security]) and at rest.
Developers should also follow standard application security best practices, such as testing APIs for the standard OWASP Top 10 vulnerabilities using static and dynamic code analysis tools. Lastly, developers should log API activities to a secure location and periodically audit for any abnormal behaviors, such as brute-force attacks on APIs.
What are the security advantages and disadvantages of using AWS APIs?
Kumaraswamy: AWS APIs and authentication mechanisms are proprietary to Amazon and limited to managing AWS infrastructure-as-a-service resources. AWS [REpresentational State Transfer] APIs are protected using a signed request model which uses [an] HMAC [Hash-based Message Authentication Code] signature-based authentication model. HMAC uses a hash function combined with a symmetric key that is shared between the client and AWS services. AWS clients sign every API request based on a combination of information in the request (such as the AWS service, region, action and timestamp) and an AWS private key that is shared with the developer. The AWS API security mechanism offers verification of identity of the user (nonrepudiation), integrity protection of the REST calls and protection against replay attacks. In some ways AWS authentication mechanism is similar to 2-legged OAuth (Client credentials grant).
About the author:
Jan Stafford plans and oversees strategy and operations for TechTarget's Application Development Media Group. She has covered the computer industry for the last 20-plus years, writing about everything from personal computers to operating systems to server virtualization to application development.