Common Web Application Vulnerabilities: Types, Impact and Defences

Web application vulnerabilities are security weaknesses in web-based software that attackers exploit to steal data, hijack sessions, or execute unauthorised code. The most dangerous types, defined by the OWASP Top 10 and MITRE’s CWE database, include injection flaws, security misconfiguration, CORS misconfigurations, open redirects, and race conditions.

• Key Takeaway 1: Most web application vulnerabilities aren’t exotic. They come from poor input validation, weak server configs, and developers trusting user-supplied data they shouldn’t.
• Key Takeaway 2: OWASP, MITRE, and the NVD give you free, authoritative references. Learn to read them early.
• Key Takeaway 3: Every vulnerability class has a conceptual fix. Understanding the fix matters as much as understanding the flaw.
• Key Takeaway 4: You must have written authorisation before testing any system. No exceptions.
• Key Takeaway 5: Dedicated vulnerable-by-design apps like DVWA and OWASP Juice Shop exist precisely so you can practise legally.

Input and Inclusion Flaws: Where User Data Becomes a Weapon

The single biggest source of web application vulnerabilities is untrusted input. When an application takes data from a user and passes it directly to a file system, database, or interpreter without checking it first, things go wrong fast.

Local File Inclusion (LFI)

A local file inclusion vulnerability occurs when a web application uses a user-controlled variable to load a file from the server’s own file system. If the developer writes something like include($_GET['page']) without sanitising the input, an attacker can manipulate the parameter to read sensitive files such as /etc/passwd on Linux servers or configuration files containing database credentials.

The impact is serious. Attackers can read source code, extract secrets, and in some configurations chain LFI with log poisoning to achieve remote code execution. According to Veracode’s State of Software Security report (2024), inclusion and path traversal flaws appear in roughly 1 in 5 scanned applications, making them one of the most persistent web application vulnerability categories year after year.

The fix is straightforward in principle: never pass raw user input to file-loading functions. Use an allowlist of permitted filenames, store file references in a server-side map, and validate against that map. The CWE-98 entry in MITRE’s Common Weakness Enumeration database documents this flaw in full detail.

SQL Injection and Cross-Site Scripting (A Quick Note)

LFI sits alongside SQL injection (CWE-89) and cross-site scripting (CWE-79) in the input-flaw family. SQL injection ranked first in the MITRE CWE Top 25 Most Dangerous Software Weaknesses (2023), with XSS ranking second. Both follow the same root cause: unsanitised input reaching a sensitive interpreter. Parameterised queries fix SQLi; output encoding fixes XSS. The principle is always the same — validate input early, encode output late.

Configuration and Boundary Flaws: Misplaced Trust at the Perimeter

Some of the worst breaches don’t involve clever exploit chains. They happen because someone left a default password in place, misconfigured a cloud storage bucket, or wrote a CORS policy that trusts everyone. These are security misconfiguration vulnerabilities, and they are depressingly common across web applications of every size.

Security Misconfiguration

A security misconfiguration vulnerability covers a wide range: default admin credentials, verbose error messages that expose stack traces, unnecessary services left running, unpatched software, and cloud storage set to public read. OWASP lists Security Misconfiguration as A05 in the OWASP Top 10 (2021). The IBM Cost of a Data Breach Report (2023) found misconfigured cloud environments contributed to breaches with an average cost of USD 4.45 million, the highest in the report’s history at that point.

In India, CERT-In advisories consistently flag exposed admin panels and default credentials on government and financial portals as a leading cause of web application security incidents. India’s Digital Personal Data Protection Act (DPDP Act) 2023 now creates direct legal liability for organisations that fail to implement reasonable security safeguards, making misconfiguration a compliance risk as well as a technical one. The fix is a hardened baseline: disable defaults, apply the principle of least privilege, automate configuration audits, and run regular scans with tools like OpenVAS or Nessus.

CORS Misconfiguration

A CORS vulnerability arises when a server’s Cross-Origin Resource Sharing policy is too permissive. If an API reflects the Origin header back without validating it, or sets Access-Control-Allow-Origin: * on authenticated endpoints, a malicious website can make cross-origin requests on behalf of a logged-in user and read the response.

This is a significant risk for Indian fintech and banking APIs, where session tokens and account data ride on those responses. The correct fix is to maintain an explicit allowlist of trusted origins server-side, never reflect arbitrary origins, and never combine Access-Control-Allow-Credentials: true with a wildcard origin.

Open Redirect Vulnerability

An open redirect vulnerability exists when an application accepts a URL parameter and redirects the user to it without validating the destination. Attackers use this to build convincing phishing links: the URL starts with a legitimate domain, so users trust it, but they end up on a malicious site.

A typical pattern looks like https://trustedbank.com/login?next=https://evil.com. The fix is to validate redirect destinations against an allowlist of internal paths, or strip external URLs entirely. Open redirects are classified under CWE-601 in MITRE’s database.

Vulnerability	OWASP / CWE Reference	Primary Impact	Core Fix
Local File Inclusion	CWE-98, OWASP A03	File read, RCE via log poisoning	Allowlist filenames, never use raw user input in file paths
Security Misconfiguration	CWE-16, OWASP A05	Unauthorised access, data exposure	Hardened baselines, disable defaults, automate audits
CORS Misconfiguration	CWE-942, OWASP A05	Cross-origin data theft	Explicit origin allowlist, never wildcard + credentials
Open Redirect	CWE-601, OWASP A01	Phishing, credential theft	Validate destination against internal path allowlist
Race Condition	CWE-362, OWASP A04	Double-spend, privilege escalation	Atomic transactions, mutex locks, server-side state checks

Logic and Timing Flaws: When the Order of Operations Breaks Everything

Race Condition Vulnerability

A race condition vulnerability happens when two or more operations compete to read and write shared state, and the application assumes they will always happen in a safe order. In web apps, the classic example is a payment or coupon system: a user sends two simultaneous requests to redeem a discount, and both pass the already-used check before either one writes the used flag. Both succeed. The attacker gets double the benefit.

This class of web application vulnerability, also called a Time-of-Check to Time-of-Use (TOCTOU) issue under CWE-362, is especially dangerous in fintech. India’s UPI ecosystem processes over 13 billion transactions per month (NPCI, 2024), and any race condition in a payment or rewards flow represents a direct financial risk at that scale.

The fix involves atomic database transactions, mutex locks on critical sections, and idempotency keys so duplicate requests are detected and rejected server-side. Never rely on client-side state to prevent double submission.

How to Prevent Web Application Vulnerabilities

Preventing web application vulnerabilities requires a layered approach. No single control is sufficient. The following practices address the root causes across all the vulnerability classes covered above.

• Input validation and output encoding: Validate all input against a strict allowlist on the server side. Encode all output before rendering it in a browser or passing it to an interpreter.
• Parameterised queries: Never concatenate user input into SQL strings. Use prepared statements with bound parameters for every database interaction.
• Hardened configuration baselines: Remove default credentials, disable unused services, restrict error output in production, and automate configuration drift detection.
• Explicit CORS policies: Maintain a server-side allowlist of trusted origins. Audit every API endpoint that handles authenticated requests.
• Atomic transactions and idempotency: Use database-level locking and idempotency keys to eliminate race conditions in financial and state-changing operations.
• Regular scanning: Run automated DAST tools (OWASP ZAP, Burp Suite) and SAST tools as part of your CI/CD pipeline. Treat security findings as build-blocking defects.

Best Tools for Web Application Security Testing

Understanding web application vulnerabilities is only useful if you can find them. These tools are widely used by security professionals and are referenced in certifications like CEH and OSCP.

• OWASP ZAP: Free, open-source DAST scanner. Good for automated crawling and active scanning of web applications.
• Burp Suite Community Edition: The industry-standard proxy for manual web application testing. Intercept, modify, and replay HTTP requests.
• Nikto: Command-line web server scanner. Fast for identifying misconfigurations and outdated software.
• SQLMap: Automated SQL injection detection and exploitation tool. Use only on systems you are authorised to test.
• Nessus / OpenVAS: Vulnerability scanners that cover network and web application misconfigurations at scale.

Where to Practise Legally: Vulnerable Websites for Testing

Practising on real systems without permission is illegal under India’s Information Technology Act, 2000, and equivalent laws worldwide. Purpose-built vulnerable websites for testing let you sharpen your skills against real web application vulnerabilities without any legal risk.

• DVWA (Damn Vulnerable Web Application): A PHP/MySQL app you run locally. Covers SQLi, XSS, LFI, command injection and more, with difficulty levels.
• OWASP Juice Shop: A modern Node.js app with 100+ intentional vulnerabilities. It is the closest thing to a real-world app in a safe container.
• WebGoat: Built by OWASP specifically for teaching. Each lesson explains the concept, then asks you to exploit it yourself in a guided way.
• Hack The Box: A competitive platform with real machine challenges. Requires registration and operates under a clear terms-of-service that constitutes your authorisation.
• TryHackMe: Browser-based, beginner-friendly, with structured learning paths. Widely used by students in India preparing for CEH and OSCP certifications.

The organisation that maintains the computer vulnerabilities and exploits databases is MITRE, which runs the CVE (Common Vulnerabilities and Exposures) programme. The National Vulnerability Database (NVD), maintained by NIST, enriches CVE entries with severity scores (CVSS), references, and patch information. Both are free and should be part of your regular reading as a security professional.

If you want a structured path from these fundamentals into professional certification, the ethical hacking courses at 3.0 University cover web application security as part of a full curriculum. The Certified Ethical Hacker v13 programme maps directly to EC-Council’s CEH exam objectives and includes hands-on lab work with environments similar to those listed above.

Your next steps are practical. Set up DVWA locally this week. Read the OWASP Top 10 (2021) in full — it is free and takes about two hours. Create an NVD account and start following CVE advisories for technologies you use. Then pick a structured course so you are building toward a credential employers recognise.

Frequently Asked Questions

What are the most common web application vulnerabilities?

The most common web application vulnerabilities, according to the OWASP Top 10 (2021), include broken access control, cryptographic failures, injection flaws (SQLi, LFI), security misconfiguration, and insecure design. MITRE’s CWE Top 25 reinforces this list, with SQL injection, XSS, and out-of-bounds writes consistently ranking at the top across millions of scanned codebases worldwide.

What is an open redirect vulnerability?

An open redirect vulnerability occurs when a web application accepts a user-supplied URL and redirects the browser to it without checking whether the destination is trusted. Attackers use this to build phishing links that appear to start on a legitimate domain. The fix is to validate all redirect destinations against a strict allowlist of permitted internal paths before issuing the redirect.

What is a CORS misconfiguration?

A CORS misconfiguration happens when a server’s Cross-Origin Resource Sharing policy trusts origins it should not. If an API reflects arbitrary origins or uses a wildcard with credentials enabled, a malicious site can make authenticated cross-origin requests on behalf of a victim user and read the response. Fix it by maintaining a server-side allowlist of trusted origins and never combining wildcard origins with credentialed requests.

What is local file inclusion?

Local file inclusion is a web application vulnerability where an application uses unsanitised user input to load a file from its own server. An attacker manipulates the input to read sensitive files like configuration data or system files. In worse cases, it can be chained into remote code execution. The defence is to never pass raw user input to file-loading functions and to use an explicit allowlist of permitted files.

How do I practise finding web application vulnerabilities legally?

Safe, legal options include DVWA (run locally), OWASP Juice Shop, and WebGoat for self-hosted practice. For online platforms, Hack The Box and TryHackMe both operate under terms of service that authorise your testing within their environments. Always confirm you are working inside the designated practice scope. Never test any system without understanding the authorisation boundary first.

Which laws govern web application security testing in India?

In India, unauthorised access to computer systems is an offence under the Information Technology Act, 2000, specifically Sections 43 and 66. The DPDP Act 2023 adds data protection obligations for organisations handling personal data. Always obtain written authorisation before conducting any security test, and ensure your scope agreement is documented before you begin.

Last updated: June 2025. Reviewed by the 3University editorial team.