Availability and safety are some of the most important implicit factors to the user experience of your platform’s users. When we discuss web security to ensure these factors, images of criminal rings using sophisticated techniques come to mind. Even if your data seems too low of worth for this scenario, perhaps the over-caffeinated, zit-faced script kiddie wreaking havoc on your operations is a fear.
However, the all-too-common reality in the API world is that your worst enemies are often your worst customers. Irresponsible or unknowledgeable developers writing super chatty apps. Opportunistic partners who look to take advantage of data that gives them value, in the form of high volume traffic, and no value for you in return. Scarier yet are users whose security tokens are compromised, leaving everything from users’ personal information to financial transactions at risk (now we might be talking about criminals again!).
Certainly, there are plenty of API gateway solutions that will provide tools to counter some of these issues. That said, knowing the risks and needs makes shopping for and/or building solutions a lot easier. Said more precisely, understanding the threat vectors that are awaiting your API, even if you aren’t dealing with sophisticated intruders, is critical to your operational success.
If we learned anything from Web 1.0-2.0, it was that the business of handling anonymous users is inherently risky. Its safest to have the ability to identify traffic from specific users who are not providing security credentials, and throttle or disable them. Providing throttling or disabling tokens at this level can provide protection to your infrastructure in situations where excessive traffic is coming in from one user. Simply put, don’t allow unidentified API calls. Some sort of tokenization strategy which provides visibility to which application and which user/device are accessing your API is a big advantage when the situation gets critical.
These same principles are true for authenticated users, but not as often overlooked.
While we don’t think of coders as being particularly chatty people, quite often their application code can create spurious calls to our API platforms. While it can be inconvenient for users of your platform, disabling an entire application can often keep loads at safer levels for all of your other users. Be sure to have an app token that you can disable at the farthest point away from your infrastructure.
Of course, if you’re forced to protect your infrastructure by invalidating tokens, be courteous and contact the chatterbox developer and ask them politely to turn down the noise in their code. Work together to come up with a schedule to re-enable their access.
These are really scary sounding terms for many developers. One of the common misconceptions is that rigorous filtering of all of your users’ input is a sound strategy. In light of today’s super integrated infrastructures, it’s likely other sources outside of your API are populating your system (if not today, then some day). As such, it’s always best to filter for scripting in the input and output of your API (as well as any other applications touching your data). Don’t re-invent the wheel; there are solid libraries and other solutions for high performance filtering in virtually all web-friendly languages.
Threat identification AKA metrics
While these situations and many others can threaten the security and stability of your systems, visibility is the front-line. “Measure what you treasure” holds true with all web infrastructure.
Specifically with APIs, the ability to see where noisy consumers are coming from is the only way that your tools for throttling/disabling/etc can ever be successful. Identifying the key metrics will be slightly different for many businesses, based on domain specifics. However, a few key metrics trends are fairly universal to API operations:
- Number of calls per resource/verb/application/user
- Average response time per resource/verb/application
With these basic metrics, you should be able to at least identify spikes in utilization or response. This should be the minimum required to identify application or user tokens which need attention.
In conjunction with a broader network and application security strategy, these tactics should help keep your API safe from the developers and users it serves, as well as the nefarious ninjas of the internet.
Image credit: logos / 123RF Stock Photo