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.
Anonymous users
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.
Chatty developers
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.
Cross-site scripting/XSS
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
Nice work. I’d say that injection concerns are just as high on the priority list when it comes to external facing APIs. These APIs often to go databases which are data rich. Great prey for curious hackers or devs.
Definitely a great point. I debated the inclusion of SQL attacks…it’s trickier as lots of APIs are on non-SQL backends these days. However variations of XSS attacks are far more universal. That said SQL injections are still high on the OWASP list, and clearly a concern.
OData provides a whole new dimension to SQL Injection attacks. Although it’s not SQL itself, the premise that OData is “like ODBC for the Web” sends a shiver down the spine of any security person. JavaScript injection also could be a fruitful attack method, given that many API clients simply run eval() on the JavaScript they receive, which again is shocking to security folks. I guess I’m biased as a vendor here (Axway/Vordel) but there is a need for more awareness and shielding of these types of attacks. This article is great to throw some light on the problem. At the moment, the API is the “soft underbelly” for many organizations, in terms of security vulnerability.