Why There Is No API Security

Whether we see them or not, application programming interfaces (APIs) are a crucial part of business today. They are used in virtually every aspect of IT and DevOps. APIs facilitate and even drive B2B and B2C partnerships, ecommerce acceleration, systems and application automation, and solution integrations. Without them, business and IT shops would not be able to deliver services anywhere near as fast and efficiently as they do today. However, this speed comes at a cost. User security is often a trade-off between security and usability and there seems to be a similar trade-off with leveraging APIs.

Businesses are pushing their application APIs harder to be more robust, flexible (a.k.a. open), and faster. API programmers often have to stretch the limits of operation to accept a wide variety of inputs. Even if a specification is produced to tell other programmers how the interface should be used, it is impossible to ensure that those same programmers will not misuse or otherwise find loopholes in the specification—but it is assured that threat actors will do just that. Though we have recourse with legitimate programmers, we do not have the same luxury with threat actors trying to do the same for malicious or otherwise nefarious purposes. This creates a problem for everyone using APIs to support business because they are simultaneously creating attack vector on their accessible API-enabled applications. While programmers can perform input validation, character filtering, and other checks on inputs to ensure they meet certain security requirements, security organizations will need to identify enhanced protection external to the application that has application-level intelligence for the inputs.

It is also interesting to note that insecurity with APIs has become pervasive enough that the Open Web Application Security Project (OWASP) added two areas of insecurity to their 2017 proposed list for Top 10 application vulnerabilities. Coming in at designation A7 is “Insufficient Attack Protection,” followed at designator A10 by “Underprotected APIs.” These are not a badge of honor. In fact, their rise to fame is a tragedy. As if we didn’t have enough to worry about, we created two new areas of concern with a failure to self-regulate the way we create and manage APIs. For More information on the new OWASP Top 10 click here to download the document.

[You might also like: Why ISP DDoS Services Typically Fail]

To understand why APIs inherently lack security, you must understand that API exploits attempt to compromise the application in one of two ways. The first is through application programming errors that attempt to reveal data or impair the operation of the application. These exploits manifest themselves through malicious inputs like SQL injection, cross-site scripting, and other such attempts at exposing data. Generally, applications can be secured against programming errors. This is often an iterative approach that can take months to years of use, testing, patching and retesting, but it can be done.

The second avenue is through attempts to exploit the business logic of the application to create unauthorized access or fraudulent transactions. The harder portion to identify and stop are the exploits of business logic. Applications are being designed to deliver micro-services which expose a large number of interfaces to the Internet. This creates a larger attack surface with a net effect of providing threat actors the opportunity to attack each micro-service rather than a single application, creating a greater risk to the organization that attackers can get access to data. Because applications exploit various facets of operation rather than programming flaws, they require a greater understanding of operation than programming checks. No single part of the application, nor any part of normal Internet filtering firewall defense, has enough visibility into the context to stop business exploits. Some examples of business logic exploits are:

  • Modification of authentication flags and privilege escalations
  • Business constraint exploitation/modification or business logic bypass to generate fraudulent transactions
  • Requested parameter modification
  • Developer’s cookie tampering and business process/logic bypass
  • Exploiting clients’ side business routines embedded in JavaScript, Flash, or Silverlight
  • Identity or profile extraction
  • LDAP parameter identification and critical infrastructure access

Business logic attacks are not trivial in their consequences and are successful on even the largest organizations. A few of the large organizations that fell victim to business logic flaws are FacebookNokia, and Vimeo.

There are multiple approaches to protect against business logic exposure from outside the application. Two of the most prominent are prevention and continuous monitoring. Prevention requires testing both initial development and throughout the API and application lifecycle. It is critical not to take shortcuts on this lifecycle process with so much riding on the success or failure of business-critical applications. Continuous monitoring can be done through vulnerability scanning to identify programming errors, but not to identify business logic errors. Protection from business logic errors requires technologies that are both API- and application-aware so when fraudulent, probative, erroneous, or otherwise bogus inputs arrive, they can be detected and filtered. This is a primary function of a Web Application Firewalls were designed to do.


Read the 2016–2017 Global Application & Network Security Report by Radware’s Emergency Response Team.

Download Now

David Monahan

David is a senior information security executive with over 15 years of experience. He has organized and managed both physical and information security programs, including Security and Network Operations for organizations ranging from Fortune 100 companies to local government and small public and private companies. He has diverse Audit and Compliance and Risk and Privacy experience – providing strategic and tactical leadership, developing, architecting and deploying assurance controls, delivering process and policy documentation and training, as well as other aspects associated with educational and technical solutions. Aside from his full-time practice in the security field, David has been an adjunct faculty member for Capitol College in Laurel, Maryland since 2007, providing security instruction on both the undergraduate and graduate level. He has also presented briefings to numerous forums including SANSFire, Forrester and the Colorado Digital Government Conference.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program


An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Security Research Center