Applying Lessons from The Lord of the Rings to Web API Security – Part 1

One Does Not Simply Hack APIs… Actually, One Probably Does

Posted: February 12, 2021

Geek Alert

Before you read further into this first blog post of my two-part series, be warned that I am about to make analogies comparing Web API security to the epic fantasy trilogy The Lord of the Rings by J.R.R. Tolkien. Yes, I am unapologetically going full geek in this short series. One good thing: if you’ve only seen the movies, you should still be able to relate. Two potentially bad things: there are spoilers if you haven’t seen the movie or read the books, and I also might get flamed by Tolkien ultra-fans for bringing in parts of both the books and the movie into the comparison (I’ve already done it in the title). I won’t apologize for that, either.

Since you’re fully aware of the perils ahead and are still reading, I’ll assume you’re intrigued beyond measure and want to learn how I came to dream up this analogy – or you’re at least tolerating the premise without cringing too much. I’ll take what I can get, so let’s get this adventure started!

Starting the Journey

While there are many great scenes in the books and movies, one of my favorite parts comes very close to the beginning of the series. The group (a.k.a. the Fellowship of the Ring) starts on their journey to destroy the Ring of Power, and they’re having a heck of a time making any progress. Let’s list out some of the issues they’re having:

  • They run through a list of paths to take to get to Mount Doom (the only place they can destroy the Ring), and they decide to take a mountain pass. But an extremely strong snowstorm – which the group suspects is magically created by their enemies – hits them on the pass and they turn back to take an alternative path.
  • After the failure of the mountain pass, they decide to go through the dwarven Mines of Moria as a shortcut. But it takes a bit to find the doors, because the door was designed to only be found when the Moon shines upon it.
  • They eventually find the door, but Gandalf the Grey (the powerful wizard leading the group) can’t figure out how to open it. Part of the writing on the door says “Speak, friend, and enter.” Gandalf tries a bunch of passwords, but the door won’t budge.
  • Gandalf eventually figures out how to get into the door: he simply says the Elvish word for “friend” (it’s “mellon”, in case you’re curious), and the door opens.

Pivoting in the Snow

Let’s look at the first bullet point from my summary: a snowstorm created by their enemies makes the Fellowship choose a different path on their journey. I am analogizing this to a cyber adversary attacking a web application via the typical path of going directly at the Web UI and looking for weaknesses. That can be flaws in authentication, authorization, scripting, field sanitization, or many others. But what if the company being attacked has a pretty mature cybersecurity program that throws up a strong “snowstorm” that the attacker can’t get through?

An example of what could be placed in the way are developers who practice secure coding techniques. Or maybe the cybersecurity team has some decent defenses in place like a finely tuned and well-maintained web application firewall (WAF) and regular vulnerability testing of the code and website. If those and other defenses are in place, it might just mean the adversary needs to take… you guessed it… another path of attack.

If the application has an API – and it likely does if it is even a fairly modern web app – then the attacker might start looking for that hidden door to see if its defenses are not as good as the first path they chose. This is consistent with a lot of attacks, even modern ones: try to find what appears to be the easiest path first, then pivot when it doesn’t pan out. The only part where this analogy breaks down is that APIs are often much easier to breach than the web UI these days. That’s because there’s been a ton of attention placed on securing the UI – though there are still a ton of flaws to be found in web apps – but API security is still fairly nascent. But before I go there, let’s hit the other analogies.

The Door is Hidden… Kinda…

OK, so the adversary is finding their path blocked (or at least too difficult) and pivots to the API. But where is it? In the book, the door to the Mines of Moria was a bit hard to find, but it wasn’t really too difficult. When they were searching, Gandalf said, “But this Door was not made to be a secret known only to Dwarves.” He even said, “…eyes that know what to look for may discover the signs.” In short, the door was hidden, but it was absolutely meant to be found and used by certain parties.

Similarly, Web APIs are also meant to be found and used by developers and others working on integrations for more efficient and direct app-to-app communication. That means they shouldn’t be hard to find. That also means an adversary is going to find them. Yet I have seen instances of APIs time and again that are not built securely or protected with strong security controls because the argument is that … wait for it… adversaries shouldn’t use the API as a path of attack. Instead, adversaries should use the Web UI as the path for attack and leave the API alone.

This is at a mind-boggling argument. And while I would at least understand it from a “security by obscurity” angle (though this has been proven time and again to not be a sound security strategy), the fact that APIs are not hard to find makes it more of a “security by naivete” argument. Just as I stated in the first analogy, if the adversary can’t get in easily through one door, they will pivot to another. And if the API is a juicy target with little to no security, they will not hesitate to attack there.

In the next post of this series, I will cover the final two analogies. I’ll call them “How Does This Thing Work?” and “Speak the API Key and Enter.” Stay tuned!


This blog was written by Michael Farnum, Chief Technology Officer at Set Solutions.