Top 7 Reasons Why SOAP and REST Interfaces Are Littered With Vulnerabilities

Dan Kuykendall is co-CEO and CTO of NT OBJECTives, Inc., a provider of automated, comprehensive and accurate web application security software and services. Follow Dan on Twitter at @dan_kuykendall or send him an email at

Simple Object Access Protocol ( SOAP) and Representational State Transfer (REST) are relatively new technologies that are increasingly showing up in modern applications like mobile applications and web services. Unfortunately, their rapid rise in popularity also brings significant and damaging security vulnerabilities. Understanding how to provide web and mobile application security against these vulnerabilities is only one small step in the right direction. Developers face a number of challenges when it comes to building secure code. Let’s look at a few of them:

  1. 1. Hurry up and mobile - Mobile applications require new technologies that developers have little or no experience securing. On top of that, development teams are pressured to release mobile applications quickly in order to remain competitive. This leaves no room for mobile application security during the planning process. Every development plan must include time for security training, design, review and testing.
  1. 2. New dogs, old tricks - New generations of developers using SOAP and REST don’t know how to avoid exposing web application security vulnerabilities like cross-site scripting (XSS), SQL injection and many more. Developers must create comprehensive validation logic on every single parameter or input on every single web page to ensure their code doesn’t have vulnerabilities.
  1. 3. Old dogs, new tricks - Experienced developers are now developing mobile and rich Internet applications using REST and SOAP. While they understand how to prevent vulnerabilities like SQL injection, they may not know that application inputs from a mobile interface that accesses the backend database can be just as vulnerable as an input on an end-user page. Again, this requires training and processes to remind developers to consider application security during development.
  1. 4. Serving many masters - The coordination and prioritization of application security vulnerabilities is a problem in many organizations. Developers have many issues to address, and building new features and fixing glaring bugs are generally of greater concern than security flaws.
  1. 5. The nature of the (SQL) beast - Most interfaces make SQL calls to a SQL database. Because it is designed to allow people to get information from the database, SQL is inherently vulnerable. As a result, SQL injection vulnerabilities are rampant. It is imperative that developers understand how to avoid SQL injection in all types of applications and technologies, from HTML web pages to REST interfaces.
  1. 6. A chain is only as strong as its weakest link - Most interfaces pass data for many parameters, and each of those parameters can be attacked in dozens of ways. As a result, developers must protect tens of thousands of vulnerabilities. A single vulnerability is all that a hacker needs to cause damage so every parameter on every page must be tested.
  1. 7. It takes a village - Development and security teams must work together to build policies and practices to avoid web and mobile application security issues. Developers cannot keep up with ever-evolving hacker techniques and depend upon the security team’s expertise. Security teams can find vulnerabilities, but must work with the development teams to get them fixed.

Ensuring application security in SOAP and REST interfaces requires more than simply understanding how to build robust code. Today’s application development teams are up against a number of obstacles that make it difficult to protect code against common vulnerabilities like SQL injection and XXS. It isn’t until organizations start making large cultural changes that include web and mobile application security awareness and training that these vulnerabilities will begin to be eradicated.

Be sure to read the next Best Practices article: Don't Waste Developers' Time With Your API Program