Top 10 Web Application Security Risks

Bot management API

Web applications (or simply, web apps) have grown to be extremely versatile and powerful, and they have changed how we share and receive online information as well as conducting online business.

As a result of this, many businesses have now shifted the majority if not all of their operations to web applications. On the other hand, customer expectations have also changed: being able to access content any time on any device is now the norm, no longer a luxury.

Answering these demands creates a dilemma for online businesses: since customers demand fast and accessible information at any time, they must share a lot of data and information in their web applications. On the other hand, no web application is 100% safe. There are always vulnerabilities which hackers and cybercriminals can—and will—exploit to steal this valuable data.

Ensuring the security of your web application is a must, but as we know, it can be easier said than done. This is why we’ve put together this essential web application security checklist to help you.

As the foundation for that checklist, let’s begin by discussing some important web application risks and vulnerabilities you should know about.

Summary

Top 10 Web Application Security Risks

According to OWASP (Open Web Application Security Project), an open-source community dedicated to improving web application security, here are the ten most dangerous web application risks and vulnerabilities:

Injection

Injection vulnerabilities are any flaws that allow attackers to inject malicious code into your system—typically to an interpreter—via an application. When a web application accepts user inputs and allows these user inputs to enter the site’s database, operating system, or shell command, the web application is vulnerable to injection. Common injection types are SQL injection, NoSQL, OS, and LDAP. The injection will trick the interpreter into executing unauthorized commands, for example to access sensitive data without the right authorization.

Broken authentication

This type of vulnerability allows attackers to steal passwords, tokens, or other credentials due to incorrect implementation of session management and authentication protocols. Other types of attacks might be targeted to other vulnerabilities to assume the user’s identity.

Sensitive data exposure

The web application simply doesn’t put enough defensive measures to protect sensitive data. Attackers can use these vulnerabilities to steal or modify sensitive information, including identity theft, credit card fraud, gift card fraud, and other crimes. For example, when sensitive data isn’t properly encrypted during transit or at rest, attackers can take advantage and steal this data.

XML external entities

XML External Entity (XEE) attacks target applications that parse XML input (the XML processor evaluates external entity references within the XML documents, which is common in older XML processors). Attackers can use these external entities to force the system to give up internal files via internal port scanning, URI (Uniform Resource Identifier) handler, internal file shares, and DoS attacks, among others.

Broken access control

Incorrect implementation of access controls may allow authenticated users to access or do something they aren’t supposed to. Attackers can exploit these vulnerabilities to access the same unauthorized data or functionality.

Security misconfiguration

Various types of misconfigurations might be included in this category, for example, incorrect HTTP header configuration, insecure default configurations of the system, error messages containing sensitive data/information, etc. All libraries, frameworks, and assets within the web application must be securely configured and patched/updated regularly.

Cross-site scripting

Also called XSS, this type of vulnerability occurs when an application includes untrusted data in a web page without proper escaping or validation. XSS is also common when an existing web page is updated with user-supplied data (via API) that can create JavaScript or HTML. Attackers can use XSS to execute scripts in the target’s browser.

Insecure deserialization

Serialization is the process of converting complex data into a simpler, ‘flatter’ format. Deserialization, on the other hand, is a process to restore the serialized data to a replica of the original data. When deserialization is performed insecurely, attackers can exploit it to perform remote code execution or to perform various other attacks (injection attacks, privilege escalation attacks, etc.)

Using components with known vulnerabilities

It is common for web applications to use faulty components like frameworks, libraries, modules, and other elements, and attackers can exploit these known vulnerabilities to launch attacks like server takeovers or identity theft.

Insufficient logging and monitoring

Lack of logging, monitoring, and timely response are often exploited by hackers so they can launch the attack without being detected. It’s very important for website owners and/or system administrators to monitor the website’s traffic accordingly, to detect anomalies and prevent further attacks.

In theory, complete input and output sanitization or escaping could eliminate all ten of these vulnerabilities. However, thorough sanitization is typically not a practical option since most web applications are updated regularly and new data/inputs are constantly being added. Obviously, there are also cases where the web application is integrated with other applications, making complete sanitization even more difficult if not downright impossible.

With that being said, our job with the web application security checklist below is to bring the web application as close as we can to the ideal condition where thorough sanitization is implemented.

Web application security checklist

This web application security checklist will help you eliminate most potential web application vulnerabilities, both during the development of the application and during usage.

1. Basic checklist

A Web Application Firewall (WAF) won’t completely prevent web application attacks, but you should treat WAFs as a prerequisite for web application security best practices. Make sure to also
- Manually review the web application, identify entry points and client-side codes. Classify content hosted in third-party servers.
- Test the application’s authorization thoroughly. Look for potential path traversals, access control issues for both vertical and horizontal issues, insecure/missing authorizations, and direct object references.
- Secure all data transmissions, check for randomness and weak algorithms
- Optimize the web application’s anti-DDoS measures by testing SQL wildcard, HTTP protocol DOS, account lockout, anti-automation testing, and others.
Always use a secure random number generator whenever you need RNG
When using external libraries, make sure to always use the latest version of the external library to ensure all security vulnerabilities have been patched.
Always check access policies for every action and retrieval of data
Block old browsers (more than 3 years old) and Captcha those that are more than 2 years old when they access your web app
Check all error messages and debug output so they don’t leak important and sensitive information
Use high-level libraries for cryptography. Unless you’re an expert, don’t implement your own cryptographic algorithms.

2. File inclusion

Only take file names for inclusions from trusted lists, do not allow file names from user inputs
- If user inputs must be allowed, validate them against a, allow-list.
When delivering and reading files with user-supplied file names, validate these file names to avoid path traversal. Ensure the user is allowed to read the file
Avoid having scripts read and pass through files if possible
Ensure the application runs only with the absolutely required privileges

3. File upload

Only perform file uploads when they are absolutely required
When allowing user uploads, make sure the files cannot be interpreted as script files by your interpreter and/or web server. Check the file extension accordingly.
Disable script execution in the upload directory whenever possible
For image-only uploads, consider re-compressing image files using a secure library to ensure validity
Make sure the file extension matches the actual type of file
Prevent users from uploading risky file types (CSS, HTML, Javascript, SVG, XML, and other executables). Use an allow-list approach to only allow certain file types
Prevent users from uploading special files (clientaccesspolicy.xml, .htaccess, robots.txt, and so on).
Prevent user from overwriting application files
Make sure all uploaded files are specified with the right content-type when delivered to the user
Deliver uploaded files with “Content-disposition: attachment” header whenever possible

4. Prevent Cross-Site Scripting (XSS)

Sanitize/escape anything that is not a constant before including it. Position this as close to the output as possible
Always consider the data’s context when sanitizing/escaping
- You may need to escape multiple times for multiple contexts
- Ensure the attacker can’t put anything where it’s not supposed to be
Set the right character set as close to the beginning of the program and/or as early as possible
Check for URLs in redirector scripts
Make sure the user-provided URLs are valid. Use an allow-listing approach to avoid dangerous schemes (i.e. javascript: -URLs)

5. Prevent SQL Injection

Make sure the database login used by the web app has only the access rights that are absolutely necessary
Only allow prepared statements to access the database, use stored procedures whenever possible

6. XML-related issues

Avoid using XML unless it’s absolutely necessary
Only use trusted, high-quality XML libraries, and check whether the libraries have functions that allow you to bypass escaping.
When parsing XML, ensure your parser doesn’t attempt to load external entities and DTDs.
Make sure correct escaping is applied for internal representations of data.
When performing manual escaping, make sure it handles null bytes, unexpected charsets, and others.
Use standard data formats like JSON with proven libraries, and use them correctly. This can significantly help in your escaping needs to prevent XSS attacks
For internal representations of data, always make sure that sanitizing and/or escaping is properly applied.
Ensure proper access control to the API

7. Trusted input

When in doubt about any data, treat is an untrusted
Always sanitize or escape untrusted content
Data coming from HTTP headers are always untrusted
Even when you are sure about the input but there’s no actual need to trust the data, treat it as untrusted
All POST and GET data is untrusted
Content validation is to be done server-side

8. Comparison issues

List all comparison types in your used programming language, and always use the correct ones
Use strict comparison (PHP: “===”) when in doubt
When comparing strings for equality, make sure you can check whether the strings are equal

9. Security testing

Regularly perform the following security tests:

Static application security test: or SAST, analyzes the web app in a static form. Both manual and automated testing methods. SAST can scan the web app’s source code to identify and eliminate vulnerabilities.

Vulnerability assessment: use automated software to scan the web app against known vulnerabilities.

Dynamic application security test: includes dynamic scanning of the web app in real-time, commonly requiring a proper OWASP ZAP standard.

Security assessment: also known as ethical hacking, testing the web application’s security to identify security vulnerabilities either manually or automatically.

Runtime application self-protection: or RASP, protecting live application to protect it from malicious input by inspecting the app’s behavior.

Invest in the right web application security infrastructure

Investing in the right web application security infrastructure can significantly help in preventing web application vulnerabilities.

While a Web Application Firewall (WAF) will provide useful protection against some web application security risks, it is not sufficient. Many, if not most threats, to web applications are conducted by bots, and WAFs are simply not designed for detecting and stopping these sophisticated threat vectors.A real-time threat and bot management solution is the best approach in defending against various attack vectors at the web application level.