Common Web Application Vulnerabilities

Introduction to Web Application Vulnerabilities

Web applications are the backbone of modern digital infrastructure, powering everything from e-commerce platforms to critical government services. However, the same technologies that make web applications powerful and accessible also introduce numerous security vulnerabilities that malicious actors constantly seek to exploit.

According to the Verizon Data Breach Investigations Report, web applications remain one of the most common attack vectors for data breaches. Understanding these vulnerabilities is not just for security professionals — developers, system administrators, and business stakeholders all benefit from security awareness.

The Open Web Application Security Project (OWASP) maintains the OWASP Top 10, which represents the most critical security risks to web applications. This list is updated periodically based on data from security organizations worldwide and serves as the foundation for web application security best practices.

OWASP Top 10 Overview

The OWASP Top 10 represents the consensus of security experts about the most critical web application security risks. Understanding each category helps organizations prioritize their security efforts and allocate resources effectively.

A03: SQL Injection Explained

SQL Injection (SQLi) remains one of the most dangerous and prevalent web vulnerabilities. It occurs when an attacker can insert malicious SQL statements into application queries, potentially gaining unauthorized access to databases, reading sensitive data, modifying database content, or even executing administrative operations.

# Vulnerable PHP code:
query = "SELECT * FROM users WHERE
         username = '" + username + "'
         AND password = '" + password + "'"

# Attacker input for username:
' OR '1'='1

# Resulting query (executed):
SELECT * FROM users WHERE username = '' OR '1'='1'
                                       AND password = ''

# This returns the first user, granting unauthorized access

Cross-Site Scripting (XSS) Types

Cross-Site Scripting (XSS) is a vulnerability that allows attackers to inject malicious scripts into web pages viewed by other users. Unlike SQL injection which targets the database, XSS targets the users of a web application, making it a client-side vulnerability that can steal session tokens, deface websites, or redirect users to malicious sites.

# Basic script injection
<script>alert(document.cookie)</script>

# Image tag with onerror handler
<img src=x onerror=alert('XSS')>

# Inline event handler
<div onmouseover=alert('XSS')>hover me</div>

# JavaScript URI
<a href="javascript:alert('XSS')">click me</a>

# SVG element injection
<svg onload=alert('XSS')>

A01: Broken Access Control

Broken Access Control (A01 in OWASP Top 2021) is the most critical security risk. It occurs when applications fail to properly enforce restrictions on what authenticated users are allowed to do. Attackers can exploit these flaws to access unauthorized functionality and data, such as viewing sensitive files, modifying other users accounts, or changing access rights.

A02: Cryptographic Failures

Previously known as Sensitive Data Exposure, Cryptographic Failures occur when applications fail to properly protect sensitive data. This includes data at rest (stored in databases) and data in transit (traveling over networks). The most common failures involve transmitting sensitive data over unencrypted channels or failing to encrypt sensitive data altogether.

# GOOD: Use strong hashing for passwords
bcrypt.hash(password, 12)
argon2(password)
scrypt(password)

# GOOD: Use strong encryption for data at rest
AES-256-GCM
ChaCha20-Poly1305

# GOOD: Use TLS 1.3 for data in transit
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

# BAD: Never use these
MD5, SHA1 (for hashing)
DES, 3DES (for encryption)
SSLv3, TLS 1.0, TLS 1.1

A05: Security Misconfiguration

Security Misconfiguration is one of the most common issues leading to web application breaches. It occurs when security settings are not defined, implemented, or maintained properly. Misconfigurations can exist at any level of the application stack, from the web server and database to the application framework and API.

A07: Broken Authentication

Authentication systems are responsible for verifying user identity. When these systems fail, attackers can compromise passwords, session tokens, or exploit implementation flaws to assume other users identities temporarily or permanently. Broken authentication affects applications that handle user credentials poorly.

XML External Entities (XXE)

XXE vulnerabilities occur when XML input containing references to external entities is processed by a weakly configured XML parser. Attackers can use this to read local files on the server, perform port scanning, execute remote code (in some configurations), or cause denial of service.

# Basic XXE to read local file
<?xml version="1.0"?>
<!DOCTYPE doc [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<doc>&xxe;</doc>

# XXE to cause SSRF
<?xml version="1.0"?>
<!DOCTYPE doc [
  <!ENTITY xxe SYSTEM
    "http://internal-server:8080/admin">
]>
<doc>&xxe;</doc>

# Billion Laughs Attack (DoS)
<?xml version="1.0"?>
<!DOCTYPE doc [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;">
]>
<doc>&lol3;</doc>

Cross-Site Request Forgery (CSRF)

CSRF tricks a logged-in users browser into sending unauthorized requests to a web application. Since browsers automatically include cookies with each request, the target application cannot distinguish between legitimate requests initiated by the user and forged requests sent via the attackers code.

# 1. CSRF Tokens (Synchronizer Token Pattern)
# Server generates unique token per session
<input type="hidden" name="csrf_token" value="abc123">

# 2. Double Submit Cookie
# Cookie and header must match
Cookie: csrf=abc123
Header: X-CSRF-Token: abc123

# 3. SameSite Cookies
Set-Cookie: session=xyz; SameSite=Strict
Set-Cookie: session=xyz; SameSite=Lax

# 4. Origin/Referer Header Validation
# Verify request originates from expected domain

A06: Using Components with Known Vulnerabilities

Applications today rely heavily on third-party components, libraries, and frameworks. When these components have known vulnerabilities and are used in your application, they become the weakest link in your security posture. Attackers actively scan for applications using vulnerable components.

# Node.js - npm audit
npm audit

# Python - safety
pip install safety
safety check

# Java - OWASP Dependency-Check
./dependency-check.sh --project APP --scan .

# Go - govulncheck
govulncheck ./...

# Ruby - bundler-audit
bundle-audit

A09: Insufficient Logging and Monitoring

Most successful attacks start with vulnerability probing, reconnaissance, and exploitation. Without adequate logging and monitoring, organizations cannot detect these activities in time to prevent damage. Studies show that the average time to detect a breach is over 200 days, often discovered by external parties rather than internal teams.

A10: Server-Side Request Forgery (SSRF)

SSRF occurs when web applications fetch remote resources without validating the user-supplied URL. Attackers can force the application to send crafted requests to unexpected locations, even bypassing firewall restrictions or accessing internal services that should not be exposed.

How to Prevent These Vulnerabilities

Preventing web application vulnerabilities requires a multi-layered approach combining secure development practices, automated testing, and continuous security monitoring. Here is a comprehensive strategy to protect your applications.

Security Testing Tools

Effective vulnerability identification requires both automated tools and manual testing expertise. Here are the essential tools every security professional and development team should know.

Frequently Asked Questions