SQL Injection and XSS: How the Two Classic Injection Flaws Arise and Are Prevented

SQL Injection (SQLi) and Cross-Site Scripting (XSS) are the web’s two oldest and most common vulnerabilities. They operate in different places but share one root cause: untrusted user input being interpreted as code or a query rather than data. Understanding that shared root clarifies the correct defence.

SQL Injection

SQLi occurs when user input is embedded directly into a database query. If the app builds:

"SELECT * FROM users WHERE email = '" + input + "'"

an attacker supplying ' OR '1'='1 changes the query’s logic — bypassing authentication or exfiltrating data. Impact is severe: reading/modifying data, sometimes code execution.

Defence — parameterized queries: the root fix is to never concatenate input into the query text. Parameterized queries (prepared statements) carry input as separate data, which the database never interprets as code:

SELECT * FROM users WHERE email = ?   -- input bound as a separate parameter

Add layers: a least-privilege database account, allowlist input validation, and the safe APIs of ORMs.

Cross-Site Scripting (XSS)

XSS is when an attacker’s input is reflected into a page as script, running the attacker’s JavaScript in the victim’s browser. Three main types:

• Reflected: input reflects immediately in the response (e.g., a search page).
• Stored: input is saved and later served to other users (e.g., a comment field) — the most dangerous.
• DOM-based: the reflection happens in client-side JavaScript.

Impact: session cookie theft (if not HttpOnly), actions in the user’s name, phishing, page defacement.

Defence — context-aware output encoding: the root fix is to encode user data according to the context where it is written (HTML body, HTML attribute, JavaScript, URL — each needs different escaping). Additionally, a Content-Security-Policy limits the impact of XSS, and HttpOnly prevents cookie theft via script. Modern frameworks escape by default; use escape-bypassing paths (like dangerouslySetInnerHTML) carefully.

The shared lesson

Both are solved by the same principle: keep data out of code contexts. Parameterized queries do this for SQLi; context-aware output encoding does it for XSS.

Sources: OWASP SQL Injection Prevention, OWASP XSS Prevention, OWASP Top 10: Injection.

Does your site show signs of reflected XSS or injection? CyberTestify’s active verification checks this deterministically with harmless probes on discovered entry points.