Open Web Application Security Project Top 10

As the Internet and web applications started becoming an increasingly important part of our lives, it was of paramount importance to ensure security and privacy.

The Open Web Application Security Project (OWASP) is a global non-profit committed to enhancing and facilitating application security.

The core values of OWASP are providing free and easily accessible material and information on their website to help developers with securing their applications.

One of the most noteworthy projects of the OWASP is the OWASP Top 10.

OWASP Top 10

The OWASP Top 10 is a report that is provided and regularly updated by OWASP. It outlines the major security risks for web applications and focuses on the 10 most dangerous risk factors.

These 10 points are advised by OWASP to be given adequate attention in the development and security testing process of any web application.

Here is the OWASP Top 10 from the latest report.

1. Injection

Injection attacks work by sending untrusted data to a code interpreter. As an allowed or prohibited data submission to a web application, either in the form of input or any other way.

An example of that is entering an SQL database code into an input field that is supposed to collect plain text as a username.

If the developer has not taken measures to protect the app against such an attack, this can cause the code to be executed and can result in what is known as an SQL injection attack.

To protect against this kind of attack, a developer can:

• Use data validation where any data other than plain text is rejected.
• Implement data sterilization where the suspicious part of the data is removed.
• Set controls to make sure that the minimum of application data gets exposed in case of an attack.

2. Broken Authentication

Vulnerable authentication systems can let attackers get control of user accounts and even hijack an entire system if they can crack the admin account.

A typical example of this is hackers using a list of thousands of leaked username and password combinations from a data breach. There are scripts available that can be used to try all these username password combinations.

The workaround for this vulnerability is using access controls. Developers can set the apps to limit the number of login attempts from a single IP address or adding a delay between subsequent login attempts.

3. Sensitive Data Exposure

If applications lack proper sensitive data (like financial information and personal data) protection measures, this can lead to the data ending up in the hands of criminals. They can then use this data for illegitimate purposes.

This issue can be mitigated using one of the following methods:

• Sensitive data should be encrypted.
• Caching use must be minimized and limited to extremely necessary purposes.
• Sensitive data should not be stored as far as possible.

4. XML External Entities (XEE)

The applications that parse XML (Extensible Markup Language) input are vulnerable to this kind of attack.

Hackers can use inputs that reference an external entity and can attempt to exploit a vulnerability in the parsing system.

An external entity means a virtual or physical data storage device not supposed to be a part of the system. Such an attack can hack the system into sending application data, including the sensitive part to such a device which can then be used for illegal purposes.

5.  Broken Access Control

Access control is the system of an app that controls access to information and functionality. Broken access control can make it possible for hackers to bypass the login part and execute tasks on the system that only registered users or admins are supposed to perform.

This problem can be mitigated by making sure that the application makes use of authorization tokens and uses tight access control. However, this vulnerability can also be exploited by compromising the login credentials of the users or the admin.

6. Security Misconfiguration

Security misconfiguration is the most commonly exploited vulnerability on this list. This results from using default configurations and displaying overly explanatory error messages.

For example, if an error message tells the user the details of the problem that is resulting in the error, they can exploit it to hack the system or a part of it.

To avoid this vulnerability developers need to change default credentials with secure ones, delete unused parts of the code and create more generalized error messages that do not offer any hint of the internal workings/vulnerabilities of the system.

7. Cross-Site Scripting

If a web application allows the users to add a custom code into a URL path or on any other location where it might be visible to the other users, it can result in cross-site scripting vulnerabilities.

An example of this is hackers using emails to send URLs to the users that appear legit. Any information like banking credentials entered on the page that opens can end up with the hacker. To mitigate this, it is needed to prohibit untrusted HTTP requests and educate users about avoiding suspicious links in messages and emails.

8. Insecure Deserialization

The apps that frequently serialize and deserialize data are vulnerable to this attack. Serialization is converting the data used by the apps for storage and other purposes and deserialization is the inverse of that.

If this process is not properly secured, malicious or dangerous data can become a part of the app and can compromise the security of the whole system.

9. Using Components With Known Vulnerabilities

A lot of open source code and other components like libraries are used by modern applications. Not all of these are secure. If an insecure component makes its way into a code that can result in the whole thing being compromised. A chain can only be as strong as the weakest link in it.

Security verification of all the components used in building an app is of paramount importance to ensure the security of the system.

10. Insufficient Logging And Monitoring

Many web applications do not have sufficient measures in place to detect data breaches. A data breach is detected an average of 200 days after it has happened.

This gives hackers the time to exploit the data. Application security calls for prompt detection and reporting of any data breaches to make sure that the system is secured at all times and the leaked data is secured/invalidated before it can be misused.