Common Web Application Vulnerabilities and How to Prevent Them

A web application vulnerability can cost you dearly. If it leads to a data breach, the global average cost of one reached a staggering $4.88 million in 2024, marking a 10% year-on-year increase. That’s not to mention that cyber incidents may also undermine trust in your web app.

Web apps are a favorite attack vector among hackers, accounting for 80% of incidents and 60% of data breaches in 2023. There are two reasons for that. First, web apps are likely to have particular vulnerabilities or configuration mistakes. Second, many also contain sensitive (and, therefore, valuable) data.

Let’s break down the top 10 web application vulnerabilities you should look out for to protect your web app.

Web Application Vulnerabilities: What’s in the Name?

A web application vulnerability is a flaw in the application logic, configuration, implementation, or design that renders the web application vulnerable to attacks. These attacks usually aim at the following:

• Access sensitive data (e.g., credit card information, social security numbers).
• Spread malware to users.
• Hijack computing resources (e.g., to mine cryptocurrency).
• Commit fraud (e.g., identity theft).
• Implant false information onto the page (e.g., links to fraudulent checkout pages).

Why You Should Pay Attention to Web Application Vulnerabilities

Even if your web app is custom-built from scratch, all web technologies have inherent weaknesses. It’s impossible to develop a completely secure web app without addressing those.

Overlooking web app vulnerabilities puts your application at a higher risk of data breaches and malware attacks. Those incidents, in turn, lead to reputational losses, financial issues, and hefty fines from regulators.

For example, Capital One was fined $80 million for failing to prevent a data breach in 2019. Equifax agreed to settle for a $575 million fine to the FTC following the 2017 breach.

Top 10 Web Application Vulnerabilities to Watch Out for

Let’s examine every entry on our web application vulnerabilities list, from SQL injection flaws to weak user passwords and missing function-level access control.

1. SQL Injection Attacks

Although they’ve been around for over two decades, injection flaws remain among the most common web application vulnerabilities. According to one study, SQL injection attacks are the number one source of critical vulnerabilities for 23% of web applications worldwide.

When performing a Structured Query Language (SQL) injection, the attacker inserts malicious SQL code into a query. For example, they can add a condition that always evaluates to true (e.g., 1=1) using the OR operator. Then, the query returns data for all database entries because the injected condition bypasses the intended logic.

Attackers often combine SQL injections with other attacks (DDoS, DNS hijacking) to camouflage the injection attack.

Luckily, preventing an SQL injection is fairly easy:

• Use prepared statements with parameterized queries.
• Escape all user input to prevent it from being treated as an SQL command.
• Limit permissions to the narrowest scope in dynamic SQL.

2. Broken Access Control

Access control is how the web application decides what features, capabilities, or data to make available to specific users. Think of it as a set of read/write/create/modify/delete permissions that differ across user groups.

Broken access control, in turn, means the attacker gains a wider range of permissions (up to full access) than a regular user. So, they can get unauthorized access to sensitive data or certain features.

Exploiting broken access control may involve:

• Modifying the URL to bypass access control checks
• Gaining access to or control over another user’s account by entering its ID in the URL (IDOR)
• Exploiting CORS misconfiguration to gain unauthorized API access
• Manipulating the JSON Web Token to elevate privileges

Use these measures to prevent broken access control:

• Deny access by default.
• Validate permissions on every request.
• Сombine role-based and attribute-based controls for improved granularity.
• Never rely on client-side access control checks.
• Handle lookup IDs securely to prevent IDOR attacks.

3. Broken Authentication

Also known as broken authentication and session management, these vulnerabilities in web applications relate to user authentication and session IDs. Attackers exploit weaknesses in login processes and session handling to hijack a user session, gaining unauthorized access to the user’s account.

Broken authentication attacks are more likely if your web app:

• Relies solely on passwords for user authentication
• Has no session timeouts or keeps the user logged in for too long
• Doesn’t hash and salt user passwords properly
• Doesn’t rotate and invalidate session IDs

Here’s how to prevent this type of attack:

• Require multi-factor authentication.
• Protect user passwords with proper hashing and salting.
• Implement protections against brute force attacks.

4. Cross-Site Scripting (XSS)

Cross-site scripting involves adding malicious JavaScript code to a legitimate web page via a client-side code injection. The malicious code runs when the user clicks on a link supplied by an attacker.

Attackers can attach malicious scripts to the end of a URL (reflected XSS) or post it directly onto the page with user-generated content (persistent XSS). For example, they may post executable code wrapped in <script></script> in a comment on a forum to execute a persistent XSS.

When executed, this code copies the user’s cookies, enabling the attacker to gain unauthorized access to their accounts. Alternatively, malicious code provides the attacker access to APIs along with location data, webcam data, etc.

Here’s how to prevent XSS:

• DisableHTML in user inputs.
• Validate user inputs to avoid executable code in them.
• Sanitize user inputs before displaying them to other users to filter out injections.
• Implement a web application firewall.

5. Cross-Site Request Forgery (CSRF)

Cross-site request forgery is when an attacker tricks a web app into accepting malicious requests from an authenticated (and, therefore, trusted) user. Also known as a one-click attack or session riding, CSRF often involves exploiting the fact that browsers automatically include session cookies with requests. Usually, methods like hidden forms, image tags, or XMLHttpRequests trigger these requests.

During a CSRF attack, the hacker has the unsuspecting user submit a request containing malicious code to the web app servers. This request typically performs an unwanted action, such as changing the wire transfer destination or updating the user password.

Here’s what you can do to prevent CSRF attacks:

• Implement a synchronizer token pattern in the webpage’s form.
• Issue a cookie-to-header token using SameSite cookies or the Double Submit Cookie pattern.

6. Server-Side Request Forgery (SSRF)

While a CSRF attack targets a user request to the server, an SSRF one aims to get a web server to send requests to an unintended location or execute specific commands. As a result, it tricks internal systems into sending out sensitive data to attackers or performing unauthorized actions within the internal network.

Attackers perform SSRF attacks by exploiting vulnerabilities in a system’s data import from URL or data publishing to URL functionality. They manipulate the URL structure or substitute it with a different URL.

Mitigating an SSRF attack involves the following measures:

• Create a whitelist of hostnames or IP addresses (if possible).
• Disable unused URL schemas (e.g., file://)
• Enable authentication on all internal services (e.g., Elasticsearch, MongoDB)
• Validate and sanitize input URLs before making requests.

7. Security Misconfiguration

These web application security vulnerabilities come down to mistakes in configuration that put the application at risk. Due to those errors, application security mechanisms sometimes fail to detect or prevent unauthorized access and actions or the exposure of sensitive data.

Typical failings in security configuration include:

• Enabled defaults (e.g., passwords, accounts)
• A lack of solid password checks
• Open database instances
• The use of deprecated protocols and technologies
• Error messages revealing sensitive data
• Enabled directory listings
• Unprotected files and directories
• Unnecessary features enabled (e.g., ports, privileges)
• Lack of or insufficient segmentation, containerization, or ACLs
• Unpublished or unprotected URLs accessible by unauthorized users

This type of security vulnerability is usually the result of human error or oversight. Identifying all potential exploits requires thorough penetration testing.

8. Cryptographic Failures

Previously called “sensitive data exposure,” this vulnerability emerges when your application doesn’t encrypt sensitive data like credit card information correctly. It involves leaving some sensitive data unencrypted or misconfiguration of the encryption process.

To prevent cryptographic failures, do the following:

• Determine which data requires encryption in transit and at rest.
• Take stock of current encryption methods.
• Move away from old or weak protocols (e.g., FTP, SMTP) and functions (e.g., MD5, SHA1).
• Avoid storing unnecessary sensitive data.
• Use authenticated encryption.
• Leverage cryptographic randomness whenever appropriate.
• Encrypt sensitive data in transit using methods like TLS with forward secrecy (FS) ciphers.
• Disable caching for sensitive data.

9. Weak User Passwords

Weak user credentials pose serious security risks as they lead to unauthorized access to accounts. Using brute force or dictionary attacks to match a user’s password hash with a common one, attackers can snoop around the user’s account. Moreover, they may even gain admin privileges if the compromised account allows for it.

In this case, the mitigation strategy is simple: prevent users from creating weak passwords and enforce additional security measures. Implementing policies such as password expiration and account lockout after a set number of failed login attempts significantly reduces the risk of unauthorized access. Password expiration ensures that even if an account is compromised, the credentials are updated regularly, while account lockout helps block automated attempts to guess passwords.

Here are the main characteristics of a strong password:

• Is 12 characters or longer
• Contains both uppercase and lowercase letters
• Contains at least one number
• Contains at least one special character

10. Missing Function-Level Access Control

Function-level access control (FLAC) determines whether the user has permission to access specific functionality within a web app. Missing or weak FLAC is one of the application design flaws that enables attackers to access admin-level functions without proper authorization.

If FLAC is missing, all attackers need to do is enter the correct URL to gain access to certain features or sensitive data. For example, if the admin panel is located at https://example.com/admin, and the application lacks proper access control, typing this URL will grant any user access to admin privileges without proper validation.

FLAC issues are best identified through thorough security testing, including manual code review and the use of automated tools designed to test access controls. These methods help ensure that potential vulnerabilities are caught and addressed before they can be exploited.

To discover this type of vulnerability, take the following steps:

• Browse the web app while logged in, log out, and revisit all the visited URLs. If you get the same result, FLAC is missing.
• Bruteforce common paths (e.g., /admin) while logged out.
• Try to switch the user ID to another one in the URL. If you can get information that way, FLAC needs to tighten up.

5 Best Practices to Prevent Web Application Vulnerabilities

Preventing common web application vulnerabilities requires a comprehensive strategy that involves thorough testing, WAF deployment, and secure coding practices.

1. Implement SAST/DAST Tools

Application security testing (AST) identifies web application exploits at various stages of the software development lifecycle. Usually, it includes:

• Static AST (SAST) is a white-box method that scans the source code at rest for potential vulnerabilities and flaws.
• Dynamic AST (DAST) is often viewed as a black-box approach that simulates attacks on running web applications to identify weaknesses, but it’s important to note that DAST is not necessarily limited to black-box testing. Automatic tests can be created based on the source code to enhance its effectiveness.

SAST tools can’t scan runtime applications and may produce false positives. However, they identify common vulnerabilities in the source code before compiling the build.

DAST tools, in turn, enable continuous vulnerability testing for running web apps. They spot errors in configuration, inputs, and outputs.

Both SAST and DAST can generate false positives and negatives, so continuous integration of these tools into the development pipeline, along with regular manual code review, is crucial for maintaining the effectiveness of the testing process.

Remember that SAST and DAST serve different purposes and are best used in tandem for comprehensive security coverage.

2. Conduct Penetration Testing

Penetration testing (pen testing) involves simulating the attacker’s behavior to reveal vulnerabilities and how malicious actors can exploit them. While DAST tools automate pen testing, they don’t replace human expertise, intuition, and creativity, which are crucial in executing attacks.

Here are the most widespread types of pen testing:

• Black box: testers receive no information about the system.
• Gray box: testers receive some information but no access to the source code.
• White box: testers receive full access to the system.

Pen testing is most efficient when it’s a continuous effort, so consider Penetration Testing as a Service.

3. Deploy a Web Application Firewall (WAF)

Web Application Firewalls (WAFs) are security tools that monitor traffic and filter out potentially harmful data packets. WAFs help mitigate common vulnerabilities like SQL injections and cross-site scripting (XSS). However, it’s important not to rely entirely on a WAF to protect your web application. Using a WAF to mask or hide existing vulnerabilities rather than addressing them directly can lead to a false sense of security, leaving your application exposed to more sophisticated attacks.

WAFs inspect HTTP requests (GET, POST, PUT, DELETE) from headers and query strings to the body. If any part of the request matches a malicious pattern, the WAF will block it, ensuring it never reaches the web app. While this offers a valuable layer of protection, it’s crucial to remember that a WAF should complement other security measures, not replace them.

Here are the most significant types of WAFs:

• Host-based: Integrated into the web app, offering more customizability but requiring local server resources. It can be complex to implement and maintain.
• Network-based: Hardware-based WAFs are installed locally, minimizing latency. However, they are typically the most expensive option due to the need for physical equipment and ongoing maintenance costs.
• Cloud-based: Hosted by the vendor and installed via a DNS change. This is usually the most cost-efficient and straightforward option, though some WAF features may remain a black box, limiting visibility into how they function.

4. Enforce Secure Coding Practices

To prevent web application security vulnerabilities at their root, ensure your developers follow these secure coding best practices:

• Conduct regular security audits.
• Require multi-factor authentication from users.
• Enforce strong encryption for sensitive data at rest and in transit.
• Minify and obfuscate code to make it harder to access.
• Avoid storing hardcoded credentials and security tokens in the source code, ensuring they are securely managed and kept out of the codebase before release.
• Implement continuous automated scanning and code reviews.
• Check components for known vulnerabilities before using them.
• Monitor components for new vulnerability reports.
• Keep detailed logs to detect potential incidents.
• Validate user inputs from untrusted sources.
• Set default security posture to deny.
• Adhere to the principle of the least privilege.

5. Adopt the Shift Left Security Model

The shift left security model is a development approach that ensures you address security risks and potential web app vulnerabilities as early as possible in the development cycle.

This approach requires dev, ops, and infosec teams to work together to address security concerns from the planning and design stage to development, testing, and rollout. The traditional security model, in contrast, focuses on security during the testing and deployment phases, when it becomes more difficult and costly to fix security shortcomings.

Best practices of this model include:

• Conducting threat modeling
• Enforcing security at the API level
• Integrating app and container security into DevOps
• Running automated security tests
• Upskilling development team on secure coding best practices

In Conclusion

Defending your software against common web application vulnerabilities is a continuous effort. It should combine the following practices:

• A comprehensive audit of your app’s current vulnerabilities and their remediation
• Regular and continuous security testing
• Extensive logging and monitoring for detecting security incidents
• A change in the development approach to emphasize security throughout the lifecycle

If the extent of potential exploits makes your head spin, we can build a comprehensive security program or maximize the efficiency of your current one. Our managed application security service includes regular pen tests, threat modeling, and detailed vulnerability reporting.

Get in touch with us to discuss how our cybersecurity expertise can turn your web app into an impenetrable fortress.