The APIs Malicious Hackers Love to Exploit
Although they’ve been around since the dawn of web programming, application program interfaces — more commonly known as APIs — are a foundational tool for web developers. APIs can save time and resources while offering better end-user experiences, making them increasingly popular. ProgrammableWeb found that over the past four years, more than 2,000 application program interfaces have been added to their site’s directory annually. In the next three years, API abuses will become the most common attack vector for breaching enterprise web applications.
The increased use of APIs is largely due to the recent popularity of mobile apps. Unlike traditional websites, native mobile apps manage the user interface on a device and make requests for data against APIs, thus leading developers to use them more often. Similarly, AJAX-driven websites, which refresh only specific parts of a web page rather than the entire page, use APIs to function and have grown increasingly favored in recent years.
But every great opportunity comes with high risk as well. As APIs have grown in popularity, so, too, have the threats against them. Many organizations face increasingly sophisticated attacks against not only their websites, but their APIs too.
Unfortunately, hackers are becoming adept at using companies’ APIs to gain access to sensitive user information like names, locations, and financial transactions. In a September 2018 Facebook breach, for example, hackers used APIs intended for developers creating apps through the social media company to access personal information, such as names, genders, and hometowns, of 50 million users.
So what can you do to ensure your company isn’t a victim of a breach similar to the attack on Facebook? Here are the vulnerabilities hackers love to exploit and five practices that can help you keep your APIs safe:
APIs That are Not Authenticated
If someone wants access to your API, they should be required to register an account first. Establishing a requirement like this allows you to authenticate API requests and restrict access to legitimate users who have an API key. This way, your team can track if a single account is making a significant number of requests, and will generally be able to prevent this type of misuse of the system. For example, you’ll need to register as a developer and receive a key to write against Google’s APIs. It’s a simple but necessary security step.
Insecure URLs can easily be exploited. One of the most important (and simple) things your team should do to secure your API is to use HTTPS instead of HTTP in your URL. HTTPS encrypts the information sent between a user and a server. This approach protects sensitive information, such as payment information, usernames, and mailing addresses.
When applications use HTTP to communicate with an API, all traffic can be intercepted and read at any point in the journey, such as your internet service provider or an airport wireless access point. If an attacker is able to intercept traffic, they could steal authentication credentials, access tokens or other sensitive information.
APIs That Return Too Much Data
Your team should always enforce maximum field sizes and allowed characters for incoming requests. But it’s also essential you don’t forget to check what your systems are sending back.
For instance, a typical search of a catalog of products on a clothing company’s mobile app may yield 10 to 100 results. If your return has thousands of results, then you are returning too much data — an indication that something is off. It could be a simple web app flaw or evidence that an attacker has tricked your app into returning more than it should. For example, an attacker could craft a special request that returns all items available on the company’s website, along with the item’s specific details, like the supplier and original price. This information, in turn, could be sold to a competitor.
It’s fairly easy to determine a web app’s response, and returning thousands of records in response to a product search is certainly abnormal. By monitoring input and output, it’s easy to determine which responses should be blocked automatically.
APIs Vulnerable to SQL Injections and Remote Command Executions
SQL injection and remote command execution attacks don’t only happen to websites. Most traditional web attacks show up as API attacks. Many API calls result in database calls on the backend, so checking for malicious requests with just your code won’t be sufficient. Your team needs to monitor the API payload, like the JSON or XML markup, as well as query strings, HTTP headers, and cookies.
You can do this on the backend in code or with an API gateway. However, having a web application firewall (WAF) gives another layer of protection to find and block common attacks. Most WAFs have API-specific rulesets, and both open source and commercial solutions exist.
APIs Without Extra Layers of Protection
Cross-user and cross-customer APIs can return broader sets of data, so you should set up additional levels of protection for them. I recommend enforcing an additional factor for authenticating these types of sensitive requests (such as a client-side certificate). Likewise, only allowing access to certain APIs from a company headquarters can mitigate risks. If only a limited set of users need this API, then you can restrict access for a specific IP range or ASN (the network they are coming from).
APIs are an excellent tool for developers and end-users alike. So, as API use continues to pick up, it’s essential for IT teams to make sure they are keeping them secure. As several companies have learned, failing to secure your APIs can lead to disastrous results — like a damaged brand reputation and massive customer loss. These five small steps can easily be implemented by your team to prevent a breach, protect user data, and save your company major headaches in the future.