I see a lot of people rolling out APIs without a ton of thought given to the security fundamentals. This paper is designed to help you build a model that works to protect your APIs.
Here is a summary of the issues top 10 for API Security, you can read the paper for more examples.
1. Implement Model-Approach-Controller architecture
Information security is usually very focused on dealing with threats and vulnerabilities, and less aligned with architecture. A core principle of architecture is DRY (Don’t Repeat Yourself), which means that systems should be based on design patterns that allow for scalability and manageability.
2. Know and contain your assets
The basic mapping for access control is pretty simple. Subjects (like users and clients) request access to objects (like data, applications and services), and access controls mediate the decision to grant or deny access. However, this simple subject- request-object mapping quickly becomes complex when you factor in management considerations.
3. Design for malice
Most security architectures devote the lion’s share of attention and focus to access- control services that establish the rules of engagement for authenticating and authorizing users. But what about malicious actors that are focused on defeating the system? They often know the exact protocols of the access-control system and are deliberately trying to bypass it. Or, they are trying to exfiltrate data and other valuables from the enterprise.
4. Monitor for flaws — API attacks are happening
“You don’t know who’s swimming naked until the tide goes out.“ — Warren Buffett
Mobile security gets a lot of attention, and rightly so. But look at where the attacks are happening — on the server side. Apple’s recent challenges with iCloud are a great example of this. Apple users endured high-profile breaches even though their data was generated on iPhones, stored on the iCloud server and protected by passwords. The attackers were able to crack those passwords by using a brute-force cryptanalytic attack (continuously guessing password possibilities). According to Apple CEO Tim Cook, “Apple could have done more to make people aware of the dangers of hackers trying to target their accounts or the importance of creating stronger and safer passwords.”
5. Think mobile and beyond
The mobile computing age is upon us — at this writing, there are more mobile users (1.8 billion) than web browser users. Security in the mobile age is at least as much about server-side API security as it is about securing mobile devices.
Delivering security to a wide proliferation of different kinds of clients is a daunting task. There are tens of thousands of variants to consider just in the Android ecosystem alone.
The real challenge is to define where and how to centralize security policy enforcement. If you have 18,000 different devices, you don’t have a controllable system; you have a zoo.
6. Think of sessions, not just APIs
Signing on to an API is one thing, but what about the second, third and nth call? Initial authentication differs from session authentication in that the latter is usually based on session keys. Session keys must be generated in such a way that they are not easily guessed; in practice, this means long and random identifiers. Session identifiers must be protected both in transit (for example, with TLS/SSL) and at rest, but securing a local sandbox for storing session identifiers is a major challenge today.
In addition, the API session is usually a “midstream” session. Consider a mobile application where a session is running on the client device, another is running between the client and the API gateway, and at least one more is running between the API gateway and the back end. Even in this simple example, at least three sessions fire up when the user presses thumb to glass.
7. Simplify user experience
Users don’t care about the details of identity and security protocols; they just want to use the system. Unfortunately, the security industry has historically placed users at the center of the security protocol, and asked them to make intelligent (and technical) risk- based decisions by answering questions like, “Do you trust this certificate?”
8. Simplify the developer experience
Developers are users, too. APIs can unwittingly create vulnerabilities by not arming them with sufficient knowledge. For example, a developer may hit an API too many times and degrade performance. Or a developer may not know why or how to protect API and session keys. These problems can result in Denial of Service, Privilege Escalation and other security issues.
9. Appoint an API curator
This Top 10 list is primarily focused on technology, but even in the age of machines, we humans still play an important role (for at least a few more years, anyway). As much as tech matters, it’s important to get the organizational side right, too — just publishing APIs in a haphazard manner leads to chaos. Organizations need a gatekeeper who can ensure that policies and processes have been followed before exposing the API (and all the data and functionality behind it) to the outside world.
10. Be bi-directional:Notifications, Websockets, SMS
Access-control paradigms are changing. Client/server communications mainly follow Request-Response models, but with mobile, multi-factor authentication and HTML5, we are starting to see wholly new protocols in use.
In honor of Spinal Tap we took this top ten list to eleven, read the paper for the eleventh issue, full descriptions and examples.