How are you securing your API?
It’s the age of the digital economy explosion, and massive data loads are being piped through APIs. Business, gaming, education, science, arts . . . you name it, everything works on APIs. For a world so fundamentally reliant on APIs, there’s surprisingly little focus on security.
For developers, the defaults of their frameworks are enough; or even worse, when no frameworks are being used, they think they’re following secure practices. For system admins, the default security offered by their infrastructure or service provider is what they rely on.
Not a pretty sight at all, if you ask me.
Needless to say, there’s a lot at stake, which we realize only when something truly terrible happens.
But first things first. 🙂
Why secure API endpoints?
This has to be a no-brainer, right? We need to secure endpoints because, well, that’s what the business depends on.
While that’s a strong enough argument in itself, I want to broaden the viewpoint a little and highlight other related, but equally deadly, consequences.
This is the obvious one. If someone succeeds in messing with your API endpoints, it will bring everything to a screeching halt. Security breaches can also take a lot of time to recover from, which translates to suicide in business terms. While it’s true that most businesses probably won’t be affected by an hour or two of downtime, for some it’s not permissible.
Imagine a currency exchange being down for a few minutes!
Not securing your APIs properly can land you in serious trouble, depending on which geographies or industries you’re dealing with. For instance, if you’re serving the banking industry (in the EU, especially), the cost of being discovered serving with insecure APIs will result in massive legal and compliance troubles. So much so that it might even spell the end of your business.
Being hacked is painful enough in itself, but if news gets out in the public, there’s going to be an irrecoverable loss to your brand image. For instance, Sony has been hacked very badly a few times by now, and in the security circles, the company is a laughing stock of sorts.
Even if no actual loss of data or money is incurred, good luck trying to convince your scuttling customers. 🙂
Inflated infrastructure bills
When your API runs on an infrastructure, it consumes resource (bandwidth, CPU and memory, mostly). For instance, where the API is not secured properly and malicious outsiders are able to interact with it, it’s possible for them to force the API to keep doing a lot of pointless work (running heavy database queries, for example), which can shoot up your bills for on reasons.
On platforms where automatic scaling of resources is enabled (like AWS), the outcomes can be shocking (off topic, but if you ever get caught in a soup like this on AWS, they’re quite understanding of the situation and promptly waive off the inflated bill — as of writing, at least!).
So, you might be thinking, the team that let these compromises happen will lose morale over them? Well, not quite. It’s possible that the compromises were due to weak infrastructure security, which will dishearten the developers or vice versa.
Should this happen enough time, you’ll have a culture on your hands that you’ll regret letting develop.
So let’s say there was a breach but there was no actual loss. However, your competitors will use the incident to drum up their own API and assert how much more secure theirs is (even if it’s not!). Once again, good luck trying to convince the market. 🙂
All in all, there are consequences to security breaches that go beyond losing money.
Best Practices for Securing API endpoints
Thankfully, there are certain easy-to-implement and well-understood practices that you can apply to your API endpoints for securing them. Here’s what most security experts recommend.
If your API endpoints allow API consumers to talk over
http or other non-secure protocols, you’re putting them at a big risk. Passwords, secret keys, and credit card information can easily get stolen as any man-in-the-middle attack or packet sniffer tool can read them as plain text.
So, always make
https the only option available. No matter how trivial an endpoint might seem, connecting over
http shouldn’t even be an option. TLS certificate doesn’t cost much, you can buy for as low as $20 from SSL store.
One-way password hashing
Passwords should never be stored as plain text, as in the event that a security breach occurs, all the user accounts will be compromised. At the same time, symmetric encryption should be strictly avoided, as any attacker ingenious and persistent enough will be able to break them.
The only suggested option is asymmetric (or “one-way”) encryption algorithms for storing passwords. That way, neither an attacker nor any developer or sysadmin within the company will get to read customer passwords.
Now, almost every API has a form of authentication, but in my opinion, the OAuth2 system works the best. As opposed to other authentication methods, it divides your account into resources and allows only limited access to the auth token bearer.
At the same time, another very good practice to set tokens to expire every, say, 24 hours, so that they need to be refreshed. This way, even of your token gets leaked, there’s a chance that the 24-hour deadline will reduce the impact of the breach.
Apply rate limiting
Unless you have an API that’s used by millions of people every minute, it’s a very good idea to enforce a limit of how many calls a client can make to the API in a given time window.
This is mostly to discourage bots, which can keep sending hundreds of simultaneous requests every second and make your API eat up system resources for no good reason. All web development frameworks come with a rate-limiting middleware (and if not, it’s fairly easy to add it via a library) that takes just a minute or so to set up.
This sounds like a no-brainer, but you’ll be surprised how many APIs fall for this. Validating input not just means checking that the incoming data is in a correct format, but also that no surprises are possible. A simple example is SQL injection, which can wipe out your databases if you let the query strings go by with little or no checking.
Another example is to validate the POST request size and return a proper error code and message to the client. Trying to accept and parse ridiculously large inputs will only serve to blow up the API.
Enforce IP address filtering, if applicable
If you’re into B2B services and your APIs are used by businesses from set locations, considering adding an extra layer of security that restricts IP address that can access your API. For every new location and new clients, the IP address will need to be checked against the incoming request.
Yes, it adds nuisance to onboarding, but the end result is much tighter security than can be otherwise achieved.
Tools for Increasing API Protection
Are there tools that can help us scan vulnerability, or even better, offering the first line of defense when it comes to securing APIs?
Fortunately, yes. There are several tools you can use, but be cautioned that at the end of the day no security strategy is perfect. Having said that, these tools can increase your API security manyfold, so they are recommended.
Metasploit is an extremely popular open source framework for penetration testing of web apps and APIs. It can scan your API on several different parameters and do an exhaustive security audit for different levels of vulnerabilities present.
For instance, the security scan conducted by Metasploit can tell you whether your API signatures give away the underlying technologies and operating system or not; concealing this is often half the battle won in API security.
While the open source core framework is generally enough, there are excellent paid products built on top of Metasploit that are worth a look. The pro plan is great if you want premium support and will be using the framework in depth, but is generally not necessary if your team is experienced enough.
Netsparker comes with a USP of “proof-based scanning”. In simpler terms, it’s often possible that irregular network conditions or some lesser-known API behaviors are construed as security loopholes, which are later found to be wrong.
This wastes resources as all the vulnerabilities reported need to be scanned again manually to confirm that they aren’t false positives. Netsparker says the tool is able to provide you a strong enough proof of concept for the reports, removing doubts about the weak links found.
With companies like Sony, Religare, Coca-Cola, Huawei, etc., on their client list, you can be sure that these folks are doing something right. 🙂 By the way, they also have an incredible web security blog that you should follow.
Built by SmartBear, SoapUI Pro is an intuitive and easy way of creating API tests and getting accurate, data-driven reports on them. It also integrates neatly with your CI/CD pipeline, making sure that no new code additions are compromising the security of your API.
SoapUI is able to work with Swagger, OAS, and other popular API standards, significantly reducing the time to get started. With clients like Microsoft, Cisco, MasterCard, Oracle, etc., and plans starting at $659 per annum, this is a worthy tool for more secure APIs.
Trustwave is a suite of solutions centered around security scanning and hardening. One of the unique things about this service is that it not only performs accurate threat detection on your API but also helps you understand how to fix them.
Trustwave performs what it calls context-aware scanning, meaning that once an underlying operating system or infrastructure has been detected, the service performance a series of related checks to make sure that nasty security holes related to that platform are not present.
They also boast of a strong team of security researchers who are continuously updating the service capabilities. If you’re big on compliance, Trustwave is a good solution.
If you live by the numbers and want to enjoy features such as threat reply, single-click re-running of tests after fixes, and so on, look no further!
There’s no shortage of API security tools available in the market, whether it is open source, free or commercial, or any combination of these. Feel free to explore more, and if you find something even better, please write so in the comments and I’ll be happy to include it! 🙂