Think about your applications and databases as a dartboard in a bar. Then, think of hackers and other malicious entities as patrons throwing darts at that dartboard, attempting to land a hit.
Most times, these hackers miss the board. The dartboard is small enough, and the hackers are inaccurate enough, that your applications and systems remain safe from the majority of attacks. Additionally, the hackers are also put off by the bar’s loud music, wandering patrons, and flashing lights. These represent built-in online defenses you might not even be aware you’re using, such as the Secure Socket Layer (SSL) of the Internet’s HTTPS protocol. They deter the hackers’ attempts to land a dart on your board. While your dartboard remains small, these minor, built-in defenses are largely sufficient.
But when you connect your system to the outside world using APIs, you increase the size of your dartboard immensely. You can think of it as expanding the dartboard to fill nearly the entire bar. Without proper defenses, scoring a hit (think of incidents like the 2014 Sony Pictures hack or the piles of healthcare IT breaches) becomes much, much easier for our hackers. APIs are meant to be connected to and interacted with. They provide hackers with thousands of new transactions to exploit. Part of establishing successful API security is assuming that hackers will hit your new, larger dartboard. After all, it’s almost designed to be hit.
However, if you properly limit and define the nature of users’ interactions with your APIs, you can ensure that when hackers do interact with your APIs, it’s on your terms. In the next part of this series, we’ll detail those limits and definitions, providing you with a basic picture of successful API security.
(This post is part 2 of ourBasics of API Securityseries. Start reading this series from the introduction.)
With Thriftly, we handle API security for you. Get started building simple, secure web APIs today with a free trial.