API Security Part 1: Getting Smarter About API Security

Opening your data to the world can be a frightening prospect. In my experience, it’s among the top reasons organizations are hesitant to pursue any kind of API program that’s exposed beyond their firewall ― even to support their own mobile applications. Good API management goes a long way toward addressing a majority of security issues by providing careful reporting, monitoring, and tightly controlled access to API resources, but the fear of not knowing what one does not know about API security leaves many API program leaders with an uncomfortable anxiety about what dangers may lurk just around the corner.

The good news is that basic API security, especially compared to regular network security, is not that complex to implement, monitor, or control. Much of that anxiety is unwarranted, due largely to a lack of information or experience. Like network security, the keys to success lie in constant vigilance and rapid, effective response when a security threat is identified. New technologies are emerging to automate much of these activities, making all of this even easier and providing greater peace of mind.

API Security Basics

Securing your APIs starts with a combination of good API management tools and thoughtful design of API packages and plans targeting the right audiences while limiting their access only to the data they need to get their jobs done. Tools like TIBCO Cloud Mashery make this easier on your organization by providing industry-leading tools following security best practices accessible in an interface that does not require its users to be certified security experts.

Basic security is achieved by focusing on three primary goals:

By limiting access to specific endpoints or types of data for each user based on their needs, you can control the amount of data that is released into the wild. An internal developer, for example, will likely need wider access to a set of data to accomplish their job than a third-party developer. API management tools often use a “key” mechanism to identify both applications calling the APIs and, in some cases, the end users they represent. Each key can then have access to specific endpoints turned on or off, or can filter and transform data to limit what’s actually accessible in the response payload. In TIBCO Cloud Mashery, this is all controlled through a browser-based administrative console, making it easy for non-developers to define this access without requiring a release or developer time.

Key-based access controls are helpful when you have a handful of API users and can easily manage just their access. This scheme starts to fall apart, however, once your API usage grows beyond a couple of dozen users, as managing the individual access for each user gets more time-consuming. This is where role-based access controls can save you.

Service Isolation and Separation of Concerns

Traditional role-based access, like that found in *nix operating systems, allows you to assign access to a role, then assign users to each role, thus providing consistent access restrictions to specific classes of users. While this can work well in an API environment, and can potentially be served through firewall access rules, it still has the potential to get confusing as the number of roles and users grows.

A better approach is to segment access by audience as defined by the needs of the business and separate that access through individual API packages. This better reflects the approach of your API program and can help better define roles that may otherwise be nebulous in their purpose. It takes the conversation away from access and towards anticipated usage patterns based on audience requirements.

Mashery’s built-in Packager tool is a good example of this approach. You can create packages of endpoints from the pool of resources configured in the manager. This allows you to assign the same endpoint to multiple packages, allowing for greater reuse. If the same endpoint contains data that you’d like to restrict to a specific audience, you apply filters to strip that data on a per-package basis. By applying different plan levels to each package, you can also limit access based on the number of calls made per predefined period (i.e. per day, per hour, etc.), which can limit the damage done by bad actors trying to exploit the system.

This approach allows your developers to create endpoints that contain all of the information associated with a resource one time while allowing your API program managers (which may be your product managers, enterprise architects, or other non-developer positions) to segment access to that data in an intuitive interface. In other words, developers can focus on development while program managers can focus on segmentation and customer access.

Packaging your APIs in this manner also allows you to better report and monitor usage based not only on endpoint or user but on the class of user. This can be tremendously valuable as you plan for API growth by demonstrating which endpoints are driving the most traffic and getting the most engagement from your customers.

Consistent Monitoring and Reporting

Reporting is also key to identifying potential misuse of your APIs by user and role. Most think of unauthorized access to sensitive data when they think of API misuse, but the more common issue is developers using your API in ways they were not intended to be used.

In a previous job, I managed an API for an email marketing company, which, among other things, allowed developers to add recipients to an email newsletter list using two different methods: batch uploads and individual address additions. The backend system was not optimized for individual adds, but it didn’t make sense to require a batch upload when the developer was only adding a handful of addresses to the list. We communicated this in our documentation, but that doesn’t prevent developers from misunderstanding the purpose of those endpoints.

I remember vividly having no fewer than four engineers standing over my cubicle one afternoon as we tried to figure out why the entire backend had slowed to a crawl ― affecting not only our API users but our entire customer base. It turned out a customer had ― very logically ― created a signup page that added each email individually to their list after the user had hit the submit button. The offer in this signup page was so good that it went viral ― great for the customer, not so much for us.

With a system like TIBCO Cloud Mashery in place (which we adopted not long after this incident), uncovering the cause and the application behind it would have meant looking through the reports for unusual activity, then drilling down to the actual source of those calls ― a process that should take no more than a few minutes. Instead, we spent hours digging through server logs on each of our systems and trying to catch the calls live before we realized what was happening. With no easy way to limit or control access for the application, I was reduced to calling the customer directly and explaining how they needed to change their code as soon as possible. In the meantime, we simply put their account on hold (by sending an SQL update through the mysql client), ultimately breaking their signup page until it was fixed. Needless to say, it was a poor experience for all involved.

API security is one of the keys to a successful API management program. By taking a few extra precautionary steps when setting up your API, you will have peace of mind for your API going forward. In my next post, I’ll discuss how you can go beyond the basics to modernize your security and provide even greater peace of mind while reducing downtime and improving your view into the moment-by-moment operations of your API program.