The high-level topics are:
What is the OWASP Top 10 - 2017
Reasons to Use the OWASP Top 10 - 2017
The Top 10 Issues Overview
tl;dr: the OWASP Top 10 is a list of software vulnerabilities that are commonly overlooked or ignored during development and testing, and that have been successfully exploited with various levels of harm to businesses and users. The OWASP Top 10 should be part of most if not all project requirements specifications, architecture design and/or testing plan.
This text is primarily based on OWASP Top 10 - 2017.
1 What is the OWASP Top 10 - 2017
While the original goal of the OWASP Top 10 was simply to raise awareness among developers about common software vulnerabilities, it has since become the de facto application security standard. It is, however, merely a starting point: by securing an application against the top 10 threats does not mean that the application is secure; there much more than that when it comes to secure software and information security.
A primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the consequences of the most common and most important web application security weaknesses. The Top 10 provides basic techniques to protect against these high-risk problem areas and provides guidance on where to go from here.
The 2017 release replaces the previous 2013 release. It is primarily based on over 40 submissions from application security-oriented companies, and an industry survey that received responses from over 500 individuals. All in all, the data is based on experiences and observations from hundreds of organizations and "over 100,000 real-world applications and APIs".
The survey data has been made publicly available on GitHub.
2 Reasons to use the OWASP Top 10 - 2017
The two most obvious and important reasons to pay proper attention to these top 10 issues are related to software development and software acquisitions.
For people involved in software development, it should be a matter of professionalism to be aware of the common vulnerabilities (and by extension, potentially exploitable weaknesses) and to do their best to have these issues covered in their projects.
At the very least these issues (as applicable) should be covered in testing and be fixed before the production release if discovered.
For people involved in software acquisitions, it literally pays off to require suppliers to prove that their software has been tested against these known issues. This should be stipulated either in contract or in a project requirement specification. Alternatively, a risk assessment or code review could be performed for an on-going project to discover if these issues are present.
All in all, by taking note of these issues as early as possible in a project significant time and resources (= money) can be saved instead of trying to patch the project later down the road. More importantly, if these vulnerabilities find their way to production and then get exploited, potential damages for a business can be severe depending on what kind of information was exposed.
Why take the risk?
3 The Top 10 issues overview
A1:2017 - INJECTION Injection flaws typically occur when untrusted data is accepted without being properly validated and/or encoded before being passed on to an interpreter as part of command or query. As a result, the injected code changes the intended functionality into something harmful that can access or process in unintended ways.
A2:2017 - BROKEN AUTHENTICATION Incorrectly implemented authentication and session management can make it possible to compromise user credentials, assume different user's identity, elevate access rights without authorization or exploit the system in many other ways resulting in unauthorized access to data and functionalities.
A3:2017 - SENSITIVE DATA EXPOSURE It is all too common that a web application or API does not properly protect access to sensitive data. Data can be stolen or modified unless properly protected, e.g. by applying authentication or at the very least having it encrypted (encryption at rest or in transit).
A4:2017 - XML EXTERNAL ENTITIES (XXE)Many XML processors evaluate external entity references in an XML file, which can cause all kinds of unexpected grief especially when XML (or the referred entities!) are received from untrusted sources: they can be used to disclose internal files and file shares, scan internal ports, execute remote code or denial of service attacks.
A5:2017 - BROKEN ACCESS CONTROL Even when authenticating users is handled properly, the authorization of users often leaves much to be desired. By not implementing (preferably a robust role-based) access policy or by failing to enforce the access restrictions one may enable an attacker to access unauthorized user data or system resources, or even to change the system's access rights, etc.
A6:2017 - SECURITY MISCONFIGURATION This is arguably the most common security mishap, which can be caused by a variety of mistakes, omissions, and overlooks. For example, the system might be using unsecure default configuration (e.g. the default admin password has not been changed), overly helpful error / debug messages reveal exploitable details about the system's behavior and configuration, some ad hoc configuration change might have unintended consequences, and so on. The security misconfiguration may take place at any level ranging from the operating system, third-party libraries and frameworks and/or application's business logic or settings. This topic also includes all security patches that were never installed…
A7:2017 - CROSS-SITE SCRIPTING (XSS) An application that accepts untrusted data from an external source without proper validation and escaping is vulnerable against cross-site scripting. This allows an attacker to execute unintended scripts in the user's browsers, which may result in redirection to a malicious site, having the session hijacked or having the site's page content changed in some more or less subtle ways.
A8:2017 - INSECURE DESERIALIZATION An application that fails to deserialize objects securely may end up executing unintended remote code with various harmful consequences. Alternatively (or additionally) the application might be open to replay attacks, injection attacks, and privilege escalation attacks.
A9:2017 - USING COMPONENTS WITH KNOWN VULNERABILITIES It is a common practice to utilize third-party libraries, frameworks, and other software components or services when developing a new application. It makes perfect sense: why reinvent the wheel when there is a perfectly good solution that already gets the job done? However, all these third-party solutions are subject to the same security threats and software vulnerabilities as your application is, and using an external solution with known vulnerabilities may end up compromising the application in question in various unexpected ways.
A10:2017 - INSUFFICIENT LOGGING & MONITORING No one should consider logging as something developers do to debug the application. Logging is the primary method of keeping a record of the application's various activities. Proper logging combined with active monitoring is how various misconducts can be detected, identified and ultimately reacted to. Logs are also the primary source of information after a breach has been detected and the response team is trying to figure out what exactly happened.
4 Conclusion
It is worth keeping in mind that these ten vulnerabilities are “collected from the wild”, which should give most software architects and developers as well as company managers valid cause to question if their applications have these kinds of vulnerabilities: for hostile actors these tend to be a collection of low hanging fruits that often are the first to be probed for, and when found, exploited.
Most of these vulnerabilities can be avoided or at least mitigated in the early stages of the project when selecting technologies and designing the architecture. For example, some frameworks have in-built protections against some of these vulnerabilities while there likely are suitable third-party open source -libraries that can be included in the design.
Beyond the technical solutions having a careful, systematic approach to software work as well as adhering to best practices, such as the Security Development Lifecycle (SDL), is an effective way to build secure applications.
