Secure development practices typically focus on web application security. Just as organizations take measures against the most common vulnerabilities, hackers have invested more effort into API attacks.
"At a basic level, a web API and a web app are very similar in that they are both typically code hosted on some form of web or application server, such as Apache, Tomcat or Node," said Peter Blum, a vice president of technology at Instart, a cloud service for web application performance and security.
There are plenty of differences between APIs and web applications. On the one hand, the goal of a web application is to provide a complete user experience to a client, typically delivered through a web browser. On the other hand, a web API is typically just an assortment of methods that can be invoked to perform a specific task.
But, web applications and web APIs are similar in the fact that they are both accessed over HTTP, both process input from a client and both have access to backend services, such as databases, NoSQL stores and mail servers.
Since both share the same attack surface, when breached, they can provide hackers access to a similar set of resources. Given the fact that organizations increasingly make their APIs accessible over the web, it logically follows that hackers will increase their focus on these web-based endpoints.
Common vulnerabilities
In both instances, there are common vulnerabilities between web applications and APIs, such as SQL and LDAP injections, buffer overflows and flaws with the core application stack. For example, cross-site scripting attacks tend to be more focused on web apps because they display much more content to users. "Ultimately, however, attacks against both web APIs and web apps essentially take the same approach, and equal protection needs to be taken," Blum said.
Ultimately, attacks against both web APIs and web apps essentially take the same approach, and equal protection needs to be taken.
Peter Blumvice president at Instart
In certain client-server scenarios, the client that consumes the API responses may be a native mobile app -- rather than a web browser. Because of this, you tend to see fewer reflection attacks where an adversary tries to send malicious HTML, such as an external JavaScript in the response, to end users. However, you will still need to check for and protect against other areas, such as phishing attacks via hyperlinks that could be displayed by a non-browser app consuming an API.
Evolving threat landscape
One particular API attack being seen more frequently is the use of distributed botnets via hacked end-user machines. In these cases, the requests come from consumer ISP networks, whereas in the past they originated from AWS or Microsoft Azure.
Hackers also now pace their requests to blend in with harmless users and interact with applications in the same way a human would. Attackers can reverse engineer the API interaction between a mobile app on an iPhone and the backend APIs; they then replicate the legitimate requests with malicious ones to evade detection. "With these changes, API request rates and traffic patterns are often similar to what you would expect from a human using mobile applications, making them more difficult to detect," Blum said.
Additionally, as people better protect their web apps, malicious users will attack APIs in mobile applications instead. Hackers can often perform the same activities on a mobile app that they can on a web app, such as make a purchase, check a credit card number, create a fake account or create a fake review.
Don't get caught off guard. The protection for mobile app APIs isn't as robust as what goes into websites, making it ripe for an API attack.
Dig Deeper on Software development best practices and processes
