Web applications are mission-critical tools for many organizations. However, they are not devoid of security risks, known as web application vulnerabilities. Cyber attackers can easily exploit insecure apps to cause data breaches and other cybersecurity incidents. In fact, web-based attacks are the second most common attacks faced by SMBs.

What are the most common web application security vulnerabilities? For a comprehensive overview, OWASP’s list of web app security risks is a good place to start for learning about web security issues and solutions.

OWASP (Open Web Application Security Project) is an open community that isn’t affiliated with any tech company but supports “informed use of commercial security technology.” Since 2004, OWASP has been publishing its top 10 lists of the most critical web app security risks. The OWASP top 10 - 2017 list is the recent version.

1. Injection

In this type of attack, attackers send malicious data to the code interpreter via a form or other data submission to your web app. In turn, the code interpreter processes this code as part of a command or query, manipulating the execution of the original program. Injection attacks are one of the oldest attacks towards web applications. Examples of this type of vulnerability are SQL, NoSQL, OS, and LDAP injections. 

If injection flaws are not resolved, they can cause devastating results, like: 

• Data loss;
• Data corruption;
• Disclosure of the host’s data to unauthorized parties;
• Complete system takeover.

How to secure against injection flaws:

To defend against injection flaws, separate data from commands and queries. A safe API (application program interface) can be used to do this. Two other anti-injection ways are to use a "whitelist" server-side input validation (this, however, is not a complete defense) and to use SQL controls within queries.

2. Broken authentication

Authentication refers to how an application knows who a user is. If authentication and session management is not correctly implemented for your web app, attackers can exploit the vulnerability to steal credentials (like usernames and passwords) or gain access to accounts through stolen credentials by way of credential stuffing. Other broken authentication vulnerabilities include web apps that permit the use of weak or default passwords like “12345” or “password”, using weak credential recovery processes that rely on knowledge-based Q&As (“What city were you born in?”), and not encrypting passwords. These vulnerabilities make it easy for attackers to get access to user accounts and steal data. 

How to secure against broken authorization

• Use multi-factor authentication (MFA). 
• Do weak-password checks. Implement a strong-password policy. 
• Limit failed login attempts. 
• Use a secure, server-side, built-in session manager. 

3. Sensitive data exposure

Personally identifiable information (PII) in banking and healthcare records are some of the most sensitive data out there. If such data falls into the wrong hands, these could be easily used for fraud, ID theft, and other cyber crimes. Your web app needs to be able to protect sensitive data, or risk exposing it to attackers.

How to secure against sensitive data exposure:

• Identify and classify which pieces of data are sensitive. 
• Encrypt all sensitive data at rest and in transit. 
• Use secure encryption, robust protocols, and proper key management. 
• Disable caching of sensitive data. 
• Store passwords with strong hashing functions.

4. XML External Entities (XXE)

XML (Extensible Markup Language) files store and transport data. An external entity is a URI that’s dereferenced and evaluated during XML processing. By default, poorly configured XML processors (usually the old ones) evaluate external entities within XML documents. Attackers could exploit these XML processors and use external entities to extract/expose files or perform a denial-of-service (DoS) attack.

How to secure against XXE: 

Conduct developer training to identify and mitigate XXE. Organizations could also implement other controls, like using JSON or less complicated data formats, upgrade their XML processors, use “whitelist” server-side input validation, and use static application security testing (SAST) tools for XXE detection.

5. Broken access control

While users can be authorized to use an app, they should only be allowed to do specific tasks. For instance, a user can have the privilege to view files but may not be authorized to perform changes. However, if access control is broken—meaning, the restriction on what authorized users can do isn’t adequately enforced—the flaw can be exploited. Attackers could access data or perform unauthorized functions (like create, change, or delete files).

How to secure against broken access control: 

Access control will be effective only if it’s enforced with a reliable server-side code or server-less API. If access control is appropriately enforced, there’s nothing here that can be exploited.

There are tools (like SAST and DAST) that can detect whether access control is present. However, if access control is indeed present, these tools can't verify if access control is functioning. Hence, verification still needs to be done manually. 

6. Security misconfiguration

The causes of this flaw include insecure default configurations and misconfigured HTTP headers. If there’s a security misconfiguration, there’s a chance that attackers can access part of the system’s data or functionality. In many cases, a misconfiguration can ultimately compromise the system.

How to secure against security misconfigurations:

• Have secure installation processes in place. 
• Securely configure, patch, and upgrade all OS, frameworks, libraries, and apps on time. 
• Use DAST (dynamic application security testing) to detect security misconfigurations.

7. Cross-Site Scripting (XSS)

XSS can happen via two routes: 

• When an app includes untrusted data on a new web page without doing proper validation; and
• When an app updates an existing page with user-supplied data.

XSS flaws are prevalent; they are found in roughly 2/3 of apps and occur when web apps allow users to add their own custom code. Through XSS, attackers can steal sensitive data, modify an app to extract data, send malware, destroy websites, and redirect users to malicious websites. 

How to secure against XSS:

Separate untrusted data from active browser content by: 

• using a framework that auto-escapes XSS;
• escaping untrusted HTTP requests;
• applying context-sensitive encoding; and
• using a mitigating control against XSS. 

8. Insecure deserialization

Databases, file systems, HTTP cookies, wire protocols, web services, and caching are some apps that use deserialization. Serialization is the process of converting data into a format for another purpose like storing or transmitting it to another location; deserialization is the reverse process. An attacker can insert malicious code into serialized data which then gets deserialized into a usable form. Attackers can use insecure deserialization vulnerabilities to perform remote code execution.

How to secure insecure deserialization:

While there are tools that can detect insecure deserialization, human intervention is still required for validation. The safest way: Don’t accept serialized objects from unreliable sources, and make sure deserialized data is sanitized.

9. Using components with known vulnerabilities

App components (e.g., libraries, frameworks, modules) run with the same privileges as the app. Any component can be vulnerable, especially third party components that developers use to avoid doing redundant work. If an app does have a vulnerable component, and that component is exploited, attackers could steal data or even take over a server. Because components, such as plugins, are often shared amongst web apps, a vulnerability in one component could lead to multiple sites being attacked.

This type of vulnerability usually produces minor impacts, but some of the biggest data breaches in history have been executed through this vulnerability. 

How to secure against vulnerable components:

Have a patch management process that will remove unused/unnecessary components, compare server-side and client-side components, get components only from official sources, and monitor unmaintained components. 

10. Insufficient logging and monitoring

Attackers usually start their attacks by probing first. Unfortunately, according to most studies, it takes around 200 days before a probe is detected. Worse, the probe is usually identified by external parties, not by internal processes. 

If attackers are not detected in time, their success rate increases to nearly 100%. Moreover, if monitoring is insufficient and the response is not timely, attackers can easily tamper with data or perform further attacks. 

How to secure against insufficient monitoring

• Put an effective continuous monitoring system in place to identify suspicious accounts.
• Logs must be generated in a format that can be easily read by a centralized log management solution.
• High-value transactions must have their audit trails.
• Have an incident response and recovery plan ready at all times. 

With how fast and complex web apps are developed these days, it has become imperative to be aware of web application vulnerabilities and countermeasures. Organizations – small or large – can’t afford to ignore the risks listed in OWASP’s top 10 list. Tools like Zeguro’s web application vulnerability scanner allow businesses to continuously monitor their web applications for these common vulnerabilities so that they can be fixed quickly before being exploited. Try out our solution, which also includes employee security awareness training and security policy and procedure templates, free for 30 days.