Denys Rudyi - Fotolia

Why old security threats to web applications remain today

Out with the old, in with the new, right? Not so much when it comes to application security and web application security best practices. Old dangers linger. Don’t overlook them.

Computing has changed a lot over the past decade or so -- cloud, containers, microservices and serverless capabilities to name a few. The threat environment is different, too. It changes faster and is always probing for weaknesses. Given that, you'd think that the type of vulnerabilities we see would also be new, different and reflective of greater sophistication all around, with constantly shifting security threats to web applications and web application security best practices.

But that's often not the case.

The Open Web Application Security Project (OWASP) Top 10 list provides a window into the top vulnerabilities in web applications. While these are specific to web applications, they nonetheless provide one view of how different types of vulnerabilities have become more or less common over time.

If we look at the top 10 vulnerabilities for 2007, at the top of the list is cross-site scripting (XSS). According to the report, XSS flaws "occur whenever an application takes user-supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc."

DevOps cartoon

Right behind XSS at number two is injection flaws. Again citing the report: "Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data."

Fast forward to 2017. We might reasonably expect that developers wouldn't still be shipping software with the same types of flaws. Right? After all, web application security best practices evolve, and the flaws and techniques to mitigate security threats to web applications are quite well understood. Writing your own cryptographic routines is widely recognized as almost always a Not Good Idea. The same is true of routines to sanitize inputs that could be used to inject malicious code.

Yet, take a look at the release candidate list for 2017 and what's at the top? Injection vulnerabilities. Cross-site scripting has indeed moved down the list. Well, all the way down to number three. And the list contains plenty of other old reliables as well.

To be sure, not everything is completely static. For example, underprotected APIs are called out as a new vulnerability. As OWASP puts it: "Modern applications and APIs often involve rich client applications, such as JavaScript in the browser and mobile apps, that connect to an API of some kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are often unprotected and contain numerous vulnerabilities. We include it here to help organizations focus on this major emerging exposure."

Closely related is insufficient attack protection, which is also new to the list.

Get started as a software tester

Becoming a software tester takes more than simply having the necessary skills of the trade. As expert Gerie Owen relates, being a software tester is as much about having a nimble mindset for problem solving as it is knowing a well-defined playbook.

Beyond the web application space, we see additional types of vulnerabilities that now need to be guarded against. For example, containers are a simple and efficient way to assemble, distribute and deploy software. This very simplicity can turn into a headache if the containers don't come from trusted sources and aren't scanned for contents that aren't current on security patches. And the overall scale and pace of many development and deployment processes require a much more automated workflow than in the past.

Web application security best practices must evolve to meet the new security threats to web applications, and remember the old. As we contemplate the new technologies and practices at our fingertips, also remain aware many application security practices that should be routine and well-established often aren't. Guard against those, too.

Next Steps

DevSecOps, or how to build safer software faster

Don't let security be a DevOps afterthought

Why is security for DevOps so important?


This was last published in October 2017

Dig Deeper on DevOps security

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

How can software engineers ensure application security?