In many ways, considered the “new battleground for cybersecurity” in 2023, APIs can make – or break – a business in the coming year. The fact that they’re connectors, that they underpin and pull together the majority of digital services we use daily, makes them prime targets for hacks. The holy grail of a hacker is the ultimate low-risk, high-payout option. Because APIs are the hub for so many useful back-end services, they are a single point of entry and a single point of failure. Getting by in the coming year will be a matter of properly understanding and addressing these inherent threats that, with APIs, just come with the territory.
Can’t live with them, can’t live without them
APIs are so easy, which is why in today’s digitally native, fast-moving, instant-gratification-oriented information age, they are widely in use. In fact, they’re almost ubiquitous or will be in the next few years. Apple uses The Weather Channel API to give you those nice daily updates, music apps use APIs to show you what song you’re listening to, and parking services use APIs to let you know when there’s a next available space. A recent study indicated that 97% of enterprise leaders classify API use as essential to future growth, and another shows the average number of APIs used grew 82% over last year.
One quick example will illustrate why and why they’re a prime target for hackers. At a restaurant, you interface with a waiter, not the entire cook staff. Before APIs, users (be that the enterprise or the end-user) had a much larger knowledge burden and had to know about a lot in order to get the information they needed. In other words, you had to know the menu, the cook times, the stocking options, the dish rack, and the short-order grill. Now, APIs enter the scene, and you’ve got a waiter. Finally, someone to manage all that for you and be your single point of contact for dealing with the ever-complexifying back end. APIs are great and underpin the majority of digital services today. They’ve been a boon for DevOps and have only accelerated the already break-neck digital growth. However, because there’s so much resting on them and so much information travelling to and through them, they’re also a huge liability from a security standpoint.
There can be no chink in the armour, no weak link as it is. Even at its best, an API is at significant risk. However, add unnecessary and latent vulnerabilities into the mix, and they’re a ticking time bomb.
API security vulnerabilities (and how to deal with them)
One of the most threatening vulnerabilities is the one already mentioned – their nature as interface between user and a myriad of back-end services. It puts a target on their back.
The rest are more subtle. Here are five:
- Overly permissive APIs. They already handle enough. For that reason, the API should be treated as a super-user and protected with the same precautions. Also, it might be helpful to relegate them to “average user” and operate on the principle of least privilege. Only give the requesting entity (the person interfacing with the app) what they need and keep the rest of those super-connecting superpowers disabled. One in five API security survey respondents experienced a breach due to overprivileged APIs.
- Faults in the code. True to their nature, many APIs are cut-and-pasted from open-source models. This makes a fast thing get to market even faster. And speed is great. But then we bump into the ever-present problem of security. An organisation asks a developer for an API for their spiffy new web app, and the team wants to get it out as efficiently as possible. Since it basically bridges the front and back ends, it’s not something that hasn’t been done before, and available source code exists on free repositories like GitHub. So, the team downloads a basic API tweaks it to fit the specifications and rolls it out – assuming it’s safe for use. It was tested before being published on GitHub, right? Not necessarily. Teams have to do their own checking because open-source APIs are not always updated with the latest upgrades or patches, and backdoors could exist.
- Speed over security. This was alluded to earlier, but the best way to avoid late-stage disasters is to start building APIs with security in mind. You can catch them late in the game when some QC team is doing their due diligence (hopefully) or bake security features into the design from the start. The problem is investment. If you contract with an outside API designer, they have no vested interest in whether your company faces a breach or not. It will reflect on their reputation, perhaps, but if there is nothing in the contract about security expectations, the risk is assumed by the client. Be sure to check the fine print and specify your expectations and requirements beforehand. Not all APIs are created equal, so feel free to have an in-house or third-party agency give it a once-over before you buy. It does slow down the lightning-fastness of it all, but that speed will backfire for companies that cut corners.
- Exposed (and hidden) APIs. This comes with the territory. As more and more APIs are opened to the outside world, the attack surface increases. There is a trade-off. On the one hand, exposing your APIs in an open API ecosystem allows organisations to track user/product interaction and provides valuable data. It allows clients to customise your product and helps with retention as customers get what they want. An exposed API can also combine products for enhanced user experience; some industries even demand it – banking, telecommunications, and healthcare, to name three. Ultimately, companies with an Open API strategy see a nearly 13% increase in revenue over those without one. However, before throwing the doors open, realise the risks and plan ahead: API sprawl, siloes, and security blind spots. Not to mention a statistical increase in coding errors, latent vulnerabilities, and privilege abuse.
- Every API is unique. An API can be template-developed and unique, giving it the risk profile of two different worlds. For this reason, API attacks are typically crafted custom to the API. Securing against “one and done” attacks like SQL injections and testing pre-production code will only get you so far. Like a two-edged sword, the rapid, dynamic nature of APIs requires special attention to overlooked errors and specifically programmed business logic because attackers regularly test for inroads in both.
Addressing inherent (and trending) API vulnerabilities comes down to awareness first. The primary problem is that only a few organisations see the benefits without recognising the risks. Stay smart and either train in-house or consider an API security platform built to handle the changes. A key challenge of securing APIs is that the landscape constantly evolves, changing the threats along with it. The organisations that will thrive in 2023 will be the ones that can handle the changes.