Objective 2.3High Priority11 min read

Web Application Vulnerabilities

Security weaknesses specific to web applications including SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and other input validation failures. These vulnerabilities allow attackers to steal data, hijack sessions, or compromise web servers.

Understanding Web Application Vulnerabilities

Web applications present unique security challenges because they accept input from untrusted users over the internet. Most web vulnerabilities stem from a single root cause: trusting user input without proper validation.

Core web vulnerability types:Injection attacks — SQL injection, command injection • Cross-site attacks — XSS, CSRF • Authentication flaws — Broken authentication, session management • Data exposure — Sensitive data leakage

The OWASP Top 10 tracks the most critical web application security risks and is an essential reference for web security.

Why This Matters for the Exam

Web application vulnerabilities are among the most commonly exploited and heavily tested on SY0-701. SQL injection and XSS appear frequently in exam scenarios.

Understanding these vulnerabilities is essential because web applications are the public face of most organizations—they're accessible from anywhere and handle sensitive data.

The exam tests both recognition (identifying vulnerability types from descriptions) and remediation (knowing appropriate defenses).

Deep Dive

SQL Injection (SQLi)

Inserting malicious SQL code through user input to manipulate database queries.

How SQL Injection Works:

Vulnerable Code:

  • ```sql
  • query = "SELECT * FROM users WHERE username='" + input + "'";
  • ```

Malicious Input:

  • ```
  • ' OR '1'='1
  • ```

Resulting Query:

  • ```sql
  • SELECT * FROM users WHERE username='' OR '1'='1'
  • ```
  • This returns ALL users because '1'='1' is always true.

SQL Injection Impact:

  • Data theft (dump entire database)
  • Data modification (change records)
  • Authentication bypass (login as any user)
  • Database destruction (DROP tables)
  • Command execution (in some cases)

SQL Injection Types:

TypeDescription
In-bandResults returned in application response
BlindNo visible results; infer from behavior
Out-of-bandResults sent to attacker-controlled server

SQL Injection Defenses:

  • Parameterized queries (prepared statements)
  • Input validation (whitelist allowed characters)
  • Stored procedures (with parameterization)
  • Least privilege (database accounts)
  • WAF (Web Application Firewall)

Cross-Site Scripting (XSS)

Injecting malicious scripts into web pages viewed by other users.

How XSS Works:

  • 1.Attacker injects JavaScript into web page
  • 2.Victim visits page containing malicious script
  • 3.Script executes in victim's browser
  • 4.Script can steal cookies, credentials, or perform actions

XSS Types:

Reflected XSS

  • Malicious script in URL or form input
  • Server reflects input back in response
  • Victim clicks malicious link
  • One-time, per-request attack

Stored XSS

  • Malicious script stored on server (database, comments)
  • Served to all users viewing the content
  • Persistent and affects many users
  • More dangerous than reflected

DOM-based XSS

  • Vulnerability in client-side JavaScript
  • Server never sees malicious payload
  • Executed entirely in browser

XSS Impact:

  • Session hijacking (steal cookies)
  • Credential theft (fake login forms)
  • Defacement (modify page content)
  • Malware distribution
  • Keylogging

XSS Defenses:

  • Output encoding (escape special characters)
  • Input validation (reject or sanitize)
  • Content Security Policy (CSP)
  • HTTPOnly cookies (inaccessible to JavaScript)
  • X-XSS-Protection header

Cross-Site Request Forgery (CSRF)

Tricking authenticated users into performing unintended actions.

How CSRF Works:

  • 1.User authenticates to target site
  • 2.User visits attacker's site (while still logged in)
  • 3.Attacker's site sends request to target
  • 4.Target processes request using user's session
  • 5.Action performed without user's knowledge

CSRF Example:

  • User logged into bank. Visits malicious page containing:
  • ```html
  • ```
  • Bank processes transfer using user's existing session.

CSRF Defenses:

  • Anti-CSRF tokens (unique per request)
  • SameSite cookie attribute
  • Referer header validation
  • Re-authentication for sensitive actions

Other Web Vulnerabilities

Insecure Direct Object References (IDOR)

  • Accessing objects by manipulating IDs
  • Example: /user/profile?id=123 → change to id=124
  • Access other users' data

Server-Side Request Forgery (SSRF)

  • Tricking server into making requests
  • Access internal resources
  • Bypass firewalls

XML External Entity (XXE)

  • Exploiting XML parsers
  • Read local files
  • Server-side request forgery

Directory Traversal

  • Using ../ to access files outside web root
  • Read sensitive files
  • Example: /file?name=../../../etc/passwd

Input Validation Summary

VulnerabilityWhat's InjectedWhere
SQL InjectionSQL codeDatabase queries
XSSJavaScriptWeb pages
Command InjectionOS commandsSystem calls
LDAP InjectionLDAP queriesDirectory services
XML InjectionXML/XXEXML parsers

How CompTIA Tests This

Example Analysis

Scenario: A web application displays user comments without encoding. An attacker posts a comment containing: ``. Every user who views this comment has their session cookie sent to the attacker.

Analysis - Stored XSS:

Why It's Stored XSS: • Malicious script saved to database (comment) • Served to ALL users viewing comments • Persistent—affects everyone, not just one victim • Script executes in each victim's browser

Attack Flow: 1. Attacker posts comment with JavaScript 2. Server stores comment in database 3. Other users request page with comments 4. Server serves malicious script as part of page 5. Script runs in victims' browsers 6. Cookies exfiltrated to attacker's server

Defense Measures:Output encoding — Convert < to < before display • Input validation — Reject or sanitize script tags • CSP — Restrict script execution sources • HTTPOnly cookies — Prevent JavaScript access to session

Key insight: The vulnerability is trusting user input (the comment) and reflecting it without sanitization. All injection attacks stem from this fundamental flaw.

Key Terms to Know

web application vulnerabilitiesSQL injectionXSScross-site scriptingCSRFinput validationOWASPweb security

Common Mistakes to Avoid

Thinking input validation alone stops injection—you need BOTH input validation AND output encoding/parameterization. Defense in depth.
Confusing XSS and CSRF—XSS executes attacker's script in victim's browser. CSRF tricks victim's browser into making requests.
Assuming WAFs prevent all attacks—WAFs help but can be bypassed. Secure coding is the primary defense.
Only testing for obvious injection—attackers use encoding, obfuscation, and alternative syntax to bypass filters.

Exam Tips

SQL injection = Malicious SQL in input → Database compromise.
XSS = Malicious JavaScript in pages → Session theft, defacement.
Stored XSS affects many users. Reflected XSS affects one user per click.
CSRF = Tricking authenticated users into performing actions.
Parameterized queries prevent SQL injection. Output encoding prevents XSS.
HTTPOnly cookies protect against XSS stealing sessions.

Memory Trick

"SCIX" - Major Web Vulnerabilities

  • SQL injection (attack database)
  • CSRF (trick authenticated users)
  • IDOR (access other users' data)
  • XSS (execute scripts in browsers)
  • XSS Type Memory:
  • Reflected = Returned once (via URL)
  • Stored = Saved permanently (in database)
  • DOM = Done in browser (no server)
  • Injection Defense Memory:
  • SQL → Parameterized queries
  • XSS → Encoding output
  • CSRF → Tokens (anti-CSRF)

Root Cause: ALL injection = Trusting untrusted input Defense = Validate IN, Encode OUT

Test Your Knowledge

Q1.An attacker enters ' OR 1=1-- into a login form's username field and gains access without a valid password. This exploits:

Q2.Malicious JavaScript stored in a web application's comment section executes in every visitor's browser. This is:

Q3.What is the PRIMARY defense against SQL injection attacks?

Want more practice with instant AI feedback?

Practice with AI

Continue Learning

Ready to test your knowledge?

Practice questions on web application vulnerabilities and other Objective 2.3 concepts.

Start Practice