OWASP Top 10 web application security risks

by Synopsys Editorial Team on January 9, 2019

The OWASP Top 10 2017 is a list of the most significant web application security risks. How are you addressing these top 10 web app vulnerabilities?

The Open Web Application Security Project (OWASP) is a nonprofit community of software developers, engineers, and freelancers that provides resources and tools for web application security. Every few years, OWASP releases a report on the 10 most critical web application security risks. The latest, OWASP Top 10 2017, was released in November 2017 (our own Andrew van der Stock was involved in its creation).

You might think that because the web application development landscape changes so quickly, the list of highest web app security risks would follow along. But that’s not the case. Most of the issues in the OWASP Top 10 2017 are the same as (or very similar to) the issues in the first list from 2004. The web has come a long way since then, but web app security has yet to catch up.

Sponsorships Available

Let’s review the 2017 Open Web Application Security Project Top 10 security risks from 2017.

A1: Injection

Injection happens when an attacker injects a bit of code to trick an application into performing unintended actions. The most common and well-known injection attack is SQL injection (SQLi), where an attacker inserts an SQL statement that, for example, exposes the contents of a database table. LDAP injection is a similar type of attack against a directory system. OWASP recommends you check incoming requests to determine their trustworthiness, and keep untrusted data separated from the systems that run your application.

A2: Broken authentication

Formerly “Broken authentication and session management.” You know the user credentials of people accessing your systems, but do you know who is actually behind the keyboard? Attackers can hijack user identities and hide behind genuine user IDs to gain easy access to your data and programs. Implement strong authentication and session management controls, and ensure your users are who they say they are.

A3: Sensitive data exposure

Unintended data display is a serious problem to anyone operating a web application that contains user data. Although OWASP points out that the full perils of insecure data extend well beyond the scope of the OWASP Top 10, they do recommend a handful of minimum steps—among them, encrypting all sensitive data at rest and in transit and discarding sensitive data as soon as you can.

A4: XML external entities (XXE)

XML processors are often configured to load the contents of external files specified in an XML document. An attacker can exploit this capability by having the XML processor return contents of local files, access files on other systems that trust the attacked system, or even create executable code. OWASP recommends configuring your XML processor to turn this capability off.

A5: Broken access control

This vulnerability combines the vulnerabilities “Missing function level access control” and “Insecure direct object references” from the 2013 list. Broken access control occurs when users can perform functions above their levels or gain access to other users’ information. OWASP advocates several methods to secure your applications, including establishing “deny by default” rules to allow function access only to users you trust and implementing access control checks for each user-accessible object (such as files, webpages, and other information).

A6: Security misconfiguration

“Security misconfiguration” is a general reference to application security systems that are incomplete or poorly managed. Security misconfiguration can occur at any level and in any part of an application, so it’s both highly common and easily detectable. There are myriad ways in which you may be vulnerable to software misconfiguration, so be sure to read up on OWASP’s vulnerability report.

A7: Cross-site scripting (XSS)

An XSS vulnerability extends the trust a user has given a specific site to a second, potentially malicious site. Users generally permit trusted sites to perform certain actions. But malicious actors can modify a page on a trusted site to interact with an untrusted site, exposing sensitive data or spreading malware. XSS vulnerabilities are common, but they’re not difficult to remediate. Separate untrusted, user-inputted data from active content in your webpage (for example, hyperlinks). And don’t rely on input validation.

A8: Insecure deserialization

Serialization is used to turn an object into data that can be sent somewhere or stored. In this way, the object can be recreated in the same state by another system and/or at another time via the process of deserialization. An attacker could provide an object that, when deserialized, gives the attacker access privileges or runs malicious code. This vulnerability is difficult to exploit, but it can also be difficult to detect. OWASP recommends restricting the types of objects to be deserialized, or not deserializing untrusted objects at all.

A9: Using components with known vulnerabilities

Open source development practices drive innovation and reduce development costs. But despite the benefits of open source software, the 2018 Open Source Security and Risk Analysis found that significant challenges remain in security and management practices. It’s critical that you gain visibility into and control of the open source components in your applications and Docker containers.

A10: Insufficient logging and monitoring

Sufficient logging and monitoring can’t prevent malicious actors from launching an attack. But without it, you might find it difficult to detect attacks, shut them down, and determine the scope of the damage. Insufficient logging and monitoring is common. But it’s also difficult to detect. Even if your logs are detailed enough to reveal an attack in progress, there’s no guarantee that the systems put in place to monitor those logs are working.

Gone (for now) but best not forgotten

The main differences between the OWASP Top 10 2017 and 2013 are the removal of two risks and a reordering of the rest. But don’t think that the removed web app security risks are no longer important. These vulnerabilities still exist in the wild (though less abundantly than earlier). And if we aren’t vigilant about protecting against them, they might very well resurface on future OWASP Top 10 lists.

Cross-site request forgery (CSRF)

A CSRF attack involves sending a request to a vulnerable web application using a trusted user’s credentials. Although an untrusted third party generates the request, the attacker uses the victim’s browser to piggy-back on the victim’s credibility. A CRSF attack exploits a trusted user’s authentication to trick a system into performing a malicious action. To reduce risk of forgery, OWASP suggests that you include a unique, hidden token in every web request.

Unvalidated redirects and forwards

When a web application accepts unverified input that affects URL redirects, third parties can redirect users to malicious websites. In addition, attackers can alter automatic forwarding routines to gain access to sensitive information. The Open Web Application Security Project suggests you avoid using redirects and forwards whenever possible. But if that’s unrealistic, at least you should prevent users from affecting the destination.

Who needs OWASP?

All these web security vulnerabilities are interwoven, and one vulnerability can lead to another. It’s vital to understand the application security landscape and take steps to reduce your risk. Even more important, you must determine which of the OWASP Top 10 risks apply to your systems, and which other risks you carry that aren’t mentioned here. You can use the OWASP Top 10 as a starting point for creating your own list of risks and developing a plan to keep your web applications secure. Our free eBook Who Needs OWASP? will show you how.

Get the eBook