API Security: 6 Themes for Securing Your API
Security certainly feels a lot more like a journey than a destination. This is especially true with APIs becoming a critical piece of any mobile or web application. With so much information being shared through APIs, teams need to ask themselves: how can you effectively secure your API?
While the security demands of developing and maintaining APIs will continue to evolve, there are a few key areas your team should be focused on if you have have responsibility for an Application Programming Interface (API):
Mobility, mobility, mobility. If you want to know the top three themes for 2016 (and the last few years) that would be it. Between mobile consumers who count on results while on the go, and the ongoing explosion of the Internet of Things (IoT), the most important API trends in 2016 are centered on mobile consumption.
What makes mobile API use special? Authentication, reliability, and performance constraints.
A simple-minded design might model an API client directly on a mobile device, in communication with the API server. This is rarely appropriate, though, because it entails embedding an API key on the handheld. This effectively means that the application's API key — created as a private asset of the application developer — is available to any user of the application or mobile device. This should rarely be acceptable.
It might seem that mobile native applications have the same architectural constraints as Web applications; at a sufficiently high level of abstraction, they do look much the same.
But there are also a few crucial differences.
Web browsers build in a great deal of security sophistication, particularly in regard to certificate and DNS (domain name system) management. Native applications rarely attempt, let alone achieve, the same level of authentication refinement. This is true in a couple of complementary aspects: first, only large-scale projects like browsers currently undertake such demanding technologies as HTTP Strict Transport (HSTS).
Also, Web development culture is simply more advanced in regard to coding: many Web developers at least are familiar with the idea of generation of a new token for each use of a form, as protection against Cross-Site Request Forgery (CSRF). While CSRF is a considerably smaller threat for native applications, native application programmers too often aren't even aware of their CSRF vulnerabilities.
What alternative do developers have?
One way or another, secure API-based applications essentially need communication with at least two servers. Any API key must be on an application server, either in direct communication with the API server, or at least delivering API tokens for a protocol such as OAuth.
Mobile APIs also face a reliability challenge. While traditional client-server and SOA (service-oriented architecture) applications often can assume connectivity between client and server, that's unrealistic for many mobile applications. At the very least, many of the communications of a mobile application must build in retries and more care in error-handling.
Part of the solution for these difficulties is to use standard frameworks or libraries that take responsibility for secure, reliable, and adequately-performing communications and session management. At the same time, too many frameworks encourage simple-minded fine-grained exposure of underlying database tables. It's a greater consumer benefit and almost certainly more secure to define instead a higher-level API expressed in business logic, rather than data tables or low-level object attributes. Smart developers, therefore, use a framework, but carefully craft the API to provide just what client applications need, without the excess of functionality that invites attack from crackers.
2. Community success
The second big theme for API security in 2016 is thoughtful support of the developer community. Most API publishers document their offerings to the point of a reference manual of signatures, and probably a "Hello, world!"-level sample program. One of the best investments publishers can make is in richer support of their API consumers: a collection of example programs illustrating different security practices, prompt technical support, community infrastructure for public answers to questions, and continuing education through webinars or podcasts or other means. The publisher should target, not just sale of licenses, but successful deployments of working, secure applications by its licensees. Among other pay-offs, this is a great way to prevent security incidents that tarnish the API's brand.
The previous section, on Mobility, already mentioned cultural differences between Web and native development. Cultivation of a healthy culture around that specific API is simply a winning bet. The alternative is to assume application developers teach themselves how to make the most of the API. An API worth careful, secure engineering also deserves corresponding care with its consumers.
An API publisher provides and documents an entry point such as Customer. A trustworthy API publishers knows more about Customer: how often customers request it, the variations in that rate, the distribution of latencies in delivering results to customers, the defaults customers use, and so on. An essential element of security is to log, measure, and review daily operations. Among other benefits, this enables detection of anomalies as well as prioritization of security enhancements.
Measurement is necessary for rational management on all fronts. Questions about scaling, pricing, hiring, and so on all deserve answers based on measurement of actual API usage.
Testing is a crucial theme of API security every year, not just in 2016. One aspect of functional testing especially timely now is beyond-ASCII data. Too many testing suites rely on data with the complexity of "Hello, World". When customers send through other-than-English Unicode data, errors too often turn up. When crackers experiment with carefully-crafted Unicode spoofs, vulnerabilities open up. In 2016, it's time not just to test that an API works, but that it works safely.
Read More: 8 Security Considerations for API Testing
5. API Management
Service providers — Content Developer Networks (CDNs), API gateways, API proxies, and more — offer a range of values for API publishers. Most API publishers should focus on the functionality of their APIs, while buying security, scaling, and manageability expertise outside. 2016 is a good time to explore the increasingly sophisticated marketplace for API management.
Microservices are certainly fashionable now. The implications of microservice implementations for API security are complex and beyond the scope of this survey. The starting point for such an analysis is that an API publisher clearly understand its own business and technical goals with its API: is it trying to re-use assets and reduce the costs of internal projects? Profit from the interest of external application authors? Will the API grow in traffic to a constant collection of entry points, or is the intent to extend the API "horizontally" to richer services? Is the API a fine-grained exposure of data tables, or a higher-order access to business logic? All these questions bear on the role of microservices in an API architecture.
API growth has only begun; it's still more future than past. With a little care, prospective API publishers can arrange the basic security that keeps the bad guys away, and allows focus on the functionality and customer service that deserve attention.
API Security Testing for REST and SOAP Services
Learn more about how Secure Pro can help you simulate attacks against your REST and SOAP services.