What Is SQL Injection and XSS? Web Application Attacks Explained

Web Application Security and OWASP

Web applications are the most common attack surface-cves-exploits-and-patch-management) in modern organisations. The OWASP Top 10-PCI-DSS-cybersecurity-compliance-frameworks-explained) is the standard reference for the most critical web application security risks, and injection attacks (including SQL injection) and cross-site scripting-cross-site-scripting-explained) (XSS) consistently rank among the most widespread and impactful vulnerabilities.

SQL Injection (SQLi)

What Is SQL Injection?

SQL injection occurs when an attacker inserts malicious SQL code into an input field, and that input is incorporated into a database query without proper sanitisation. If the application is vulnerable, the attacker's SQL code executes against the database.

Basic Example

A login form that builds this query:

SELECT * FROM users WHERE username = 'INPUT' AND password = 'INPUT2'

An attacker enters ' OR '1'='1 as the username:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...'

Because '1'='1' is always true, the query returns all users — the attacker logs in without a valid password.

What Attackers Can Do

| Attack | Description | |---|---| | Authentication bypass | Log in without credentials (as shown above) | | Data extraction | Dump entire tables: UNION SELECT username, password FROM users-- | | Blind SQLi | Extract data one bit at a time through true/false responses | | Out-of-band exfiltration | Send data to the attacker's server via DNS lookups | | Command execution | On some databases, execute OS commands (xp_cmdshell in MSSQL) | | Data modification | Update or delete records: '; DROP TABLE users;-- |

Types of SQL Injection

• In-band: Results returned directly in the response
• Blind: No results shown; attacker infers data from application behaviour
• Error-based: Trigger database errors to reveal information
• Time-based: Use SLEEP() functions to infer true/false conditions

Preventing SQL Injection

The only reliable defence is parameterised queries (prepared statements):

# VULNERABLE:
query = "SELECT * FROM users WHERE username = '" + username + "'"

# SAFE (parameterised):
cursor.execute("SELECT * FROM users WHERE username = %s", (username,))

With parameterised queries, user input is never interpreted as SQL code — it is always treated as data.

Additional defences:

• Stored procedures (if not dynamically built)
• input validation: Reject unexpected characters early
• least privilege: Application database user should only have SELECT/INSERT, never DROP
• WAF (web application [firewall](/learning-center/what-is-a-firewall-and-how-does-it-protect-your-network)): Can detect and block common SQLi patterns

Cross-Site Scripting (XSS)

What Is XSS?

cross-site scripting-cross-site-scripting-explained) (XSS) occurs when an attacker injects malicious JavaScript into a web page that is then executed in the victim's browser. The browser cannot tell the difference between legitimate page JavaScript and the injected code — it runs both.

Types of XSS

Stored (Persistent) XSS

Malicious script is saved in the application's database and served to every user who views the affected page.

Example: A comment on a blog post contains ``. Every user who reads that post has their session-how-the-world-wide-web-works) cookie sent to the attacker.

Reflected XSS

Malicious script is embedded in a URL and reflected back in the server's response. The victim must be tricked into clicking the link.

https://example.com/search?q=

If the server reflects the search query into the page without encoding, the script executes.

DOM-Based XSS

The vulnerability exists entirely in the client-side JavaScript — the server is not involved. The DOM is manipulated using attacker-controlled input (e.g., the URL fragment #).

What Attackers Can Do with XSS

• [session-how-the-world-wide-web-works) hijacking](/learning-center/what-is-a-man-in-the-middle-attack): Steal session cookies to log in as the victim
• credential theft-how-attackers-steal-credentials): Inject a fake login form
• Keylogging: Capture everything the victim types
• Defacement: Modify page content visible to users
• Redirect: Send victims to phishing or malware sites
• CSRF amplification: Perform actions as the victim in the same browsing context

Preventing XSS

1. output encoding-cross-site-scripting-explained): Encode special characters before inserting user input into HTML:

• < → <, > → >, " → ", ' → '

1. Content Security Policy-security-headers-CORS-HSTS-explained)-csp-hsts-explained) (CSP): HTTP header that restricts which scripts can execute:

   Content-Security-Policy: script-src 'self'; object-src 'none';

1. HttpOnly cookies: Prevent JavaScript from reading session-how-the-world-wide-web-works) cookies
2. Modern frameworks: React, Angular, and Vue automatically encode output — do not use dangerouslySetInnerHTML (React) or innerHTML without sanitisation

Cross-Site Request Forgery (CSRF)

CSRF tricks a logged-in user into submitting a request they did not intend. If a user visits a malicious page while logged into their bank, an invisible form can be submitted to transfer money:

<img src="https://bank.example.com/transfer?to=attacker&amount=1000">

Defences: CSRF tokens (random secret included in every form and validated server-side), SameSite=Strict cookie-how-the-world-wide-web-works) attribute, verifying the Referer or Origin header.

OWASP Top 10 Context

| # | Category | Includes | |---|---|---| | A01 | Broken Access Control | privilege escalation, IDOR | | A02 | Cryptographic Failures | Weak encryption, data exposure | | A03 | Injection | SQL injection, LDAP injection, command injection | | A07 | XSS | Stored, Reflected, DOM-based |

Summary

• SQL injection inserts malicious SQL into queries, allowing data theft, auth bypass, and database destruction
• Parameterised queries / prepared statements are the only reliable SQLi defence
• XSS injects JavaScript that runs in the victim's browser, stealing sessions and credentials
• output encoding-cross-site-scripting-explained) and Content Security Policy-security-headers-CORS-HSTS-explained)-csp-hsts-explained) are the primary XSS defences
• CSRF tricks authenticated users into making unintended requests — prevented by CSRF tokens and SameSite cookies
• Use a WAF as a defence-in-depth measure, but it is not a substitute for secure coding