A Closer Look: OWASP Top 10 Application Security Risks

May 22, 2017 By Arden Rubens

Open Web Application Security Project (OWASP) is an organization filled with security experts from around the world who provide information about applications and the risks posed, in the most direct, neutral, and practical way. Since 2003, the OWASP Top 10 releases a list every four years consisting of the top biggest Application Security Risks.



This list is considered an AppSec benchmark and is endorsed by the application security community. The list is compiled with the latest vulnerabilities, threats and attacks, as well as detection tactics and remediation. OWASP Top 10 project members create the list by analyzing the occurrence rates and the general severity of each threat facing our rapidly evolving application world.


The 2017 OWASP Top 10 list has recently been released for public comment. It’s based on the examination of over 2.3M vulnerabilities which impacted 50,000 applications, and contains two large-scale vulnerability updates and updated attack scenarios. Let’s take a closer look at the list as a whole and what key changes were made in OWASP Top 10 Application Security Risks 2017.


A1 – Injection

If your application is able to receive user input that goes into a back-end database, command, or call, your app is able to fall to the face of code injection attacks. Injection flaws are a set of security vulnerabilities which occur when suspicious data is inserted into an app as a command or query. Known injection attacks include SQL, OS, XXE, and LDAP.


The most common of the code injection attacks are SQL Injections, also known as SQLi. An SQLi attack is done when malformed code is sent to the database server, thus leading to the exposure of your data. And this attack style is so simple and easy, anyone with access to the internet can do it – SQLi scripts are available for download and can be acquired easily. As one of the most common vulnerabilities, we seem to know a lot about it and yet, new SQLi attacks are always popping up – just take a quick look at the SQLi Hall-of-Shame and see for yourself.


Continue your reading:


A2 – Broken Authentication and Session Management

When an application’s functions are not implemented correctly, the attack surface is open for criminals to easily break in and compromise passwords, session IDs, and exploit other flaws using stolen credentials. Sessions should be unique to each individual user, and without some necessary session management, an attacker can sneak in, disguised as a user to steal tokens and passwords to gain the access its’ after.


A3 – Cross-Site Scripting (XSS)

Cross-Site Scripting, commonly known as XSS, is a vulnerability that is often found in web apps. XSS allows attackers to inject client-side scripts into public facing web pages and, in many cases, can be used by attackers to work their way past access controls.


This is done by tricking a browser so that it accepts data from an untrusted source, and this typically happens when attackers use familiar code (such as JavaScript, for example) as developers don’t scrub out these characters.


Apps that allow user input without having full control over output may be highly at risk to XSS attacks. When an XSS attack is successful, attackers are able to cause serious damage to websites and have the ability to drag users on to other websites (often hosting more malicious code). Other known kinds of XSS attacks are Stored XSS, DOM Based XSS, and Reflected XSS.


Continue reading:


A4 – Broken Access Control

A flawed access control may be caused by unenforced user restrictions and this allows attackers to exploit and access unauthorized functionality or data. Access control is meant to control what “authorized” users are allowed and not allowed to do within an app, and to establish proper access control, the app must ensure that it is performing solid authorization checks and that proper authentication is in place to tell which users are privileged and which are in fact random internet users.


Broken access control may be due to that developers often fall to the difficulty of implementing a proper access control with all of the rules in place. And in various cases, access control rules are placed throughout the code and the collection of rules becomes scattered and nearly impossible to follow and understand.


A5 – Security Misconfiguration

Strong security requires a good and secure configuration set and deployed for apps, frameworks, servers, database, and custom code, and all should be kept up to date. Otherwise, the flaws to come as a result can be exploited by attackers and will allow them to access privileged data. Proper configuration of an application’s entire environment needs to be defined, implemented, and regulated  or it may lead to severe security holes.


A6 – Sensitive Data Exposure

Sensitive data exposures may occur when security controls – such as HTTPS – are not implemented correctly, thus leaving a hole for attackers to steal sensitive information such as passwords, payment information, IDs, addresses, and anything else you may have stored which can be of value. Applications should ensure that access be authenticated and data be encrypted. A failure of such may lead to a major privacy violation.


A7 – Insufficient Attack Protection

This category looks into how many apps and APIs today struggle to “detect, prevent, and respond to both manual and automated attacks”. The methods given include pentesting, vulnerability assessment, and using WAF or RASP as a means of detection and a quick and easy self-patch in response to an attack. This category implies that one can simply rely on source code vulnerability scanning to defend applications from simple and also sophisticated cyber attacks.


Both RASP and WAF operate inside the application and intend to detect and block attacks. While this may be an ideal scenario, RASP is still an emerging technology and many organizations are hesitant to implement it within their apps due to the obvious concerns revolving around performance, functionality, and perhaps even security. Therefore, there is IAST, which adopts a technology similar to that of RASP and is a welcomed solution for large scale organizations, as it’s designed to integrate within the application, however during the staging or testing steps.


Based on the description of A7, I do believe that organizations may have a difficult time addressing this requirement for the reasons mentioned above.  



A8 – Cross-Site Request Forgery (CSRF)

A Cross-Site Request Forgery – also known as CSRF – attack forces an authenticated end user to execute requests and actions on a web app. This is done when an attacker takes control of a victim’s browser to generate requests the vulnerable app, which defines the actions as legitimate requests from the victim.


CSRF attacks happen when a user’s browser’s HTTP is forged, letting the attacker manipulate cookies and sessions. Browsers and applications will see the requests as legitimate, often letting attackers get away with stealing the victim’s data quietly and efficiently.


Continue reading:


A9 – Using Components with Known Vulnerabilities

Component, including libraries and frameworks, may be taken from the open source community and should be used with caution in case vulnerabilities are lurking. As a vulnerable component is exploited, attackers can leverage it and cause the app serious damage and a major loss of data that can undermine the app, and perhaps even the organization.


By taking using components with known vulnerabilities, attackers can take advantage of that are easily attempt an SQLi and an XSS (among other attack methods) to attempt to takeover an occupy the app.



A10 – Underprotected APIs

In today’s application world, APIs have become the new “it” thing when it comes to many of today’s modern applications, as apps are most commonly written in JavaScript and use APIs to grab data. Therefore, APIs serve as a link between intricate client platforms and a batch of web applications or services. And while APIs may technically be web apps, securing them is not as simple as securing traditional web applications.
APIs are often left unprotected as the security of them simply may fall between the cracks, while the APIs themselves contain vulnerabilities that leave your application exposed, making this an extreme addition to this year’s list. As the list notes, APIs may use a ton of different protocols and frameworks – including SOAP/XML, REST/JSON, RPC, and GWT – and many security tools and manual pentesting are not able to successfully examine many of the used APIs due to the complex level of the protocols and frameworks, making APIs a major blind spot for the organizations using them.



jumping 1



Learn more about our supported OWASP standards

The following two tabs change content below.

Arden Rubens

Social Media Manager & Content Writer at Checkmarx
Arden is the social media manager and a content writer at Checkmarx. Her blogs focus on cyber security trends and the latest developments in the world of AppSec. She aims to educate and inspire developers, security professionals, and organizations to find the best defense against online threats.

Stay Connected

Sign up today & never miss an update from the Checkmarx blog

Get a Checkmarx Free Demo Now

Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.

Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.