Title: The OWASP Top 10 from 2017- ExplainedAuthor: ajayverma
Recently (at the end of 2017), OWASP updated its Top 10 list. For the unfamiliar, let me briefly explain what that means: the industry standard of basic-web-security education has altered. Though it’s never been a complete security education, the OWASP Top Ten is where almost all standards for web-developer security education begin. So when it changes, that’s kind of important.

There’s some substantial debate among people who think and talk about web security about the quality and substance of the OWASP changes. There’s also a lot of interest in what has changed. We’ll get to both of those things in this article, as well as offer some commentary on what’s in the Top Ten itself. In general, it remains an important and hugely useful document. To understand why, let’s start by understanding what the heck OWASP means.

What’s OWASP?

OWASP is a non-profit industry organization. The acronym stands for “Open Web Application Security Project.” It is generally regarded as one of the best sources of information about keeping the internet (and applications built upon it) secure. It’s largely a community-driven endeavor which aims to make the internet more secure by helping people to find trustworthy information about what they can do to keep their web apps and tools from getting hacked.

They throw a few conferences every year, and have a staff of about 10 people. But, they’re most notable for their Top Ten list…

What’s the OWASP Top Ten?
The OWASP Top Ten list, as you might guess, is the ten most important things that OWASP think web application developers should be focused on to make sure that the web generally is secure.

They’ve published the list since 2003, changing it through many iterations. The most recent revision was at the end of 2017. Prior to that, it was updated in 2010 and 2013. Each iteration is intended to last for quite some time.

Because the process of reaching consensus is long and time consuming, the organization has averaged an update about every-three-years. This keeps it up-to-date, but stops it from being driven too strongly by the latest trends and obsessions of the industry.

Why the OWASP Top Ten Matters

The OWASP Top Ten is a hugely influential publication. I’m a fairly-regular attendee and speaker at tech conferences, and both organizers and speakers at those events are likely to discuss the list. I’ve seen at least a few talks about various iterations of the Top Ten list in my life, and I’ve seen even more on conference calendars.

It’s certainly not the case that understanding the Open Web Application Security Project’s Top 10 list is sufficient for you to be an expert on web application security. It, for example, says nothing about how you should keep your personal passwords, or even much about how best to store passwords.

But what it is is a great baseline for discussion and processing what people want and need to know. It’s a place for a conversation about security to start, and good thing to keep an eye on for anyone who writes or maintains any part of a web application.

How the 2017 List is Different
In every update, the OWASP member-authors change the Top Ten list. That is, after all, why they update it at all. So this 2017 revision to the Top Ten was no exception there.

What was interesting about it the 2017 update, to me, was that it went through a few different drafts, and finally did some data-analysis and polling. It’s somewhere between possible and likely that this happened in the past, but because I was authoring WordPress Security with Confidence at the time, I paid much more careful attention to the whole process.

Mostly the list got consolidated and simplified. Although I feel that a few of the changes are a little confusing to me, it’s not the case that I considered the 2013 list perfect either. Some items from 2013 were consolidated, specifically around access control. And other things were added, specifically #4 XML External Entities, #8 Insecure Deserialization, and #10 Insufficient Logging. We’ll go into detail on all of that below.

Quick Rundown of the OWASP Top Ten
I admit that I don’t love that the majority of this post will be my hot takes on the OWASP Top Ten 2017. It’s a well-considered list and deserves a complete course rather than a quick summary.

But writing hot takes is kind of unavoidable on the web, if I want to offer any value to people with shorter attention spans. For those who want all the details, please check out the official PDF from OWASP. It’s great. If you’d like me to go into much more detail on any of them, please don’t hesitate to drop me a comment here. I welcome requests on this site.

OWASP Top Ten A1:2017 – Injection

“Injection” as a class of security flaw often gets shortened in my head to simply “SQL injection.” For the initiated, SQL is the language that relational databases like MySQL, Postgres, Microsoft SQL, etc speak. SQL Injection vulnerabilities come about when an unvalidated user-accessible field can have extra SQL queries like DROP TABLE users; put into the middle and executed by a database.

But one of the ways that the OWASP Top Ten #1 is different than that is that this item is intended to include things other than rational databases, like ORMs, NoSQL data stores, and anything that’d be similarly executable. Even operating system commands that are injectable, like rm -rf . are subject to this item. A big reason that this has been #1 for while (it was in 2013, 2010, etc) is the danger of this class of vulnerabilities is very high.

In general sanitization is a protection from this class of attacks, but a better one is a safe API. What this means is one where even if a use submits known bad data, nothing bad can possibly happen via that method. This is, in the case of SQL, why we prepare our queries. As even without sanitization we’re safe if we have.

A2:2017 – Broken Authentication

Like #1, the OWASP #2 for 2017 is largely similar to the same item from 2013. Authentication is the way that an application knows who a user is. Similar to Injection, “broken authentication” really contains a whole host of vulnerabilities inside of it. Both weak password storage and allowing for things like cookie stuffing via stolen session IDs are examples of this vulnerability.

Like with A1, A2 offers a lot of methods of protection. It’s a big risk because of how relatively serious it is. If you have powerful administration accounts, and it’s relatively easy for an attacker to get access to those accounts, you’ve got a serious authentication issue.

The protections are variable, because of how big an array of problems this is. OWASP mentions a variety of things, including:

Where possible, implement multi-factor authentication to
prevent automated, credential stuffing, brute force, and stolen
credential re-use attacks.
Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.
Limit or increasingly delay failed login attempts. Log all failures
and alert administrators when credential stuffing, brute force, or
other attacks are detected
A3:2017 – Sensitive Data Exposure
Officially, A3 “Sensitive Data Exposure” is shown in the OWASP Top Ten documentation as having moved down from a higher position it previously held on the 2013 list. But the title’s text is no where to be found on the previous list, and the only missing item is “Session Management” which doesn’t really apply here.

“Sensitive Data Exposure” has a really nice benefit: it’s pretty simple and clear about what the authors mean. It’s pretty clear that passwords, credit card data, secret keys, etc are “sensitive data”. And that exposing that data is bad. The complaint I have is that it’s very broad. But then again, so are #1 and #2.

Its seems to me that part of the reason for this to emerge relatively new and so high is that that the went into effect in May 2018, and that made some people take this whole question pretty seriously. The recommendation of “Don’t store sensitive data unnecessarily” is great advice, but it’s also one of the most common lessons people have taken from the GDPR. The advice contained here beyond that, of using good encryption algorithms and encrypting more data at rest are also quite good.

A4:2017 – XML External Entities (XXE)
This is the one I find myself most puzzled by. It is, in a way the first three items are not, very specific. It’s also brand new, and ranking oddly high to my eyes. It is, I think, a very specialized subclass of A1, an injection attack. OWASP’s documentation explains,


By default, many older XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. … These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks.

Now, my eyes (which think this list item isn’t great) are biased. As I’ve mentioned before (though not in this article) I mostly work on the web, and specifically in PHP. I’ve also only been doing web development for a little over five years, and largely in greenfield (new) projects. All of this comes together to mean that I’ve mostly never had to deal with XML much.

Extensible Markup Language is nice little HTML-like language which is both (two sides of the same coin) quite verbose and descriptive. It’s been a industry standard, especially for “enterprise applications”, for over ten years, going through waves of popularity and hatred.

XML and SOAP (Simple Object Access Protocol) have gone hand-in hand for years. And in my time as a developer, I’ve never really used the combination. But it’s kind of the heart of this one, so I don’t have a great deal of insight. So to provide some value to you, here are some of OWASP’s recommendations to protect against this issue:

Whenever possible, use less complex data formats such as JSON, and avoiding serialization of sensitive data.
Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system. Use dependency checkers. Update SOAP to SOAP 1.2 or higher.
A5:2017 – Broken Access Controls

Unlike my mis-givings about A4, I feel that A5:2017 is a substantial improvement over the 2013 list. In the 2013 OWASP Top Ten, both A4 and A7 were about allowing people access to functions and data they shouldn’t get. Perhaps their merger into #5 here is also the reason that A3 (above) was classed as a returner rather than new entity.

Either way, this is generally a pretty simple issue: you didn’t adequately check that someone should have access to a file or functional endpoint before you let them make use of it.

This type of vulnerability is generally caused by someone just not thinking through the implications of a server or service being publicly available. The solution is pretty simple: just assume that everything will be made public, and make every data exposure thoughtful, credential-checking, etc.

A6:2017 – Security Misconfiguration
A shift down from it’s position at #5 in 2013, this one’s largely unchanged. Like A5, it could be critiqued as so general that it borders on meaningless. Obviously a “security misconfiguration” is a security issue, if it weren’t a “security misconfiguration” it’d just be a “misconfiguration.”

But, I think this position and issue is an important and fair one to show off. The heart of it is simple: too frequently services are not done-in by explicit mistakes where people expect them, but in places where people thought they were doing things appropriately but weren’t.

The heart of this is that you must make sure that your deployments are secure-by-default, rather than spinning them up in a way that requires hardening after-the-fact. Correctly (to my mind), the author’s at OWASP recognize that after-the-deploy hardening gets skipped, so I love their recommendation to just never do it. It also fits well with the increasing Docker- or container-ization of web stacks.

OWASP Top Ten A7:2017 – Cross-site Scripting

XSS, or cross-site scripting has fallen a good distance in the 2017 revision of the OWASP Top Ten. The reason for this is that it’s so often cited as a security vulnerability, the likelihood of people making mistakes that render their application vulnerable has declined a good deal.

It’s also the case that web applications are ever better at protecting application authors by default, and so it’s less of an issue. As such, cross-site scripting vulnerability went from A3:2013 to A7:2017. I think this is a fair step, and the fact that we also have content-security policies available to further protect our applications hopefully means that this specific vector of security vulnerability will continue to fall into the background.

A8:2017 – Insecure Deserialization
While new in 2017, this type of vulnerability is not brand new. PHP applications have had this type of vulnerability for ages, because the language’s native support for a specific type of serialization. One which assumes an unrealistic amount of security in storage, and so lets the language’s unserialize call do dangerous things.

Where people use native PHP serialization, and store that data in a place where a user could control or change it, they’re vulnerable. If, like me, you write a lot of PHP, you’ll need to keep this one in mind for a long time. The easy solution is to skip PHP native serialization and instead use a common format like JSON, which PHP doesn’t preform object-magic with.

These types of vulnerabilities aren’t exclusive to PHP. The OWASP document specifies that it’s possible with at least Java as well. Basic integrity checks and/or keeping the serialized format totally secure is smart.

A9:2017 – Using Components with Known Vulnerabilities

As someone who knows a lot about WordPress security, this one has a fond place in my heart. It’s almost certainly the most common cause of compromise in WordPress, because so many end-users don’t understand the importance of updating all their components.

The basic logic and protection here is not complicated, but the position of this list has not changed because people are lazy and the tools are generally not super good. npm’s recent inclusion of an audit tool is a step in the right direction. But generally, just update everything whenever you can. And when you can’t update regular, check on the security content of new updates in your dependency graph.

This is very easy to say, but very hard to do. Especially for non-technical people who web professionals often hand off deployments like WordPress to. And so I don’t see this changing drastically in position until either tooling gets a lot better, or humans become much more concerned about this as a general security practice.

A10:2017 – Insufficient Logging
New in 2017, I think this item is sensible but a little hard-to-implement. The meaning of “sufficient” logging is complex, and an item title as short as this can’t add much clarity. So I’ll let the OWASP document speak in a little more length:

Insufficient logging, detection, monitoring and active response occurs any time:

Auditable events, such as logins, failed logins, and high-value transactions are not logged.
Warnings and errors generate no, inadequate, or unclear log messages.
Logs of applications and APIs are not monitored for suspicious activity.
Logs are only stored locally.
Appropriate alerting thresholds and response escalation processes are not in place or effective.
Penetration testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts.
The application is unable to detect, escalate, or alert for active attacks in real time or near real time.
We’re starting to better understand. The basic idea that I feel the authors are going for here is that an application should have more auditible clarity for both users and its administrators about potential security issues it can make them aware of.

This is again, easier to say than it is to do. You must build security into an entire application and its infrastructure to truly be safe from this concern, but then that feels rather appropriate to me.

Dropped or Changed from the 2013 OWASP Top Ten
If you read through the above, you may be wondering what changed between this revision and the previous. Here’s a quick summary of what changed.

Insecure Direct Object References and Missing Function Level Access Control Combined
A4:2013, and A7:2013 from the 2013 OWASP Top Ten were merged. They’re now both contained in A5:2017, or “Broken Access Control.” I think this is a great change. I discussed it a fair amount more in the above, so I won’t really add any specifics here.

A8:2013 Cross-Site Request Forgery Was Dropped
The logic here seems pretty reasonable to me: more and more form solutions for web applications have built in nonce-like protection to make applications and their users safe from the type of vulnerability where a form’s intent was subverted in the background.

Irresponsibly, I also will cop to the fact that my understanding of the exploitability of this sort of vulnerability also never computed for me, especially relative to the amount it was talked about. I think it’s prior prominence had a lot to do with CSRF being a conveniently simple acronym.

Dropped A10:2013: Unvalidated Redirects and Forwards from OWASP Top Ten
This item from the OWASP Top Ten for 2013 has also seemed a little esoteric to me. I’ve never had much vision about how I would begin to exploit it. Maybe that’s because I’m not really a nefarious cracker/hacker, or maybe it was a generally minor risk. Either way, the stated reason from OWASP for demotion of this one from this list is:

A10-Unvalidated Redirects and Forwards, while found in approximately in 8% of applications, it was edged out overall by XXE.

Now, I also think that XXE (A4:2017) is pretty obscure, but their collected data seems to support this one being more obscrue. The core ideas was and is that if you’re not careful, it’s possible for something like a URL in a query string for a redirect getting changed, and then your website sending a user to a nefarious site. It seems like a reasonable concern for sure, but the authors decided it was less important that the rest of what was kept.


Submitted On: 2019-06-27 11:50:14