If I use a WAF, do I still need to use parameterized queries?

Absolutely. A WAF is a perimeter defense that can be bypassed with obfuscation. Parameterized queries provide a fundamental fix at the data layer, ensuring that even if a malicious payload reaches your database, it cannot be executed. This is the essence of defense-in-depth.

Which is more dangerous: Stored XSS or Reflected XSS?

Stored XSS is generally more dangerous because it is persistent. While Reflected XSS requires a victim to click a specific link, Stored XSS lives on the server and automatically attacks any user who visits the infected page, leading to a much higher infection rate.

Can input validation alone prevent SQL Injection?

Input validation is helpful, but it's not enough. Attackers are experts at bypassing filters using different character encodings. Parameterized queries are the only way to truly guarantee that user input is never interpreted as a command by the database engine.

Home > Blog > CompTIA CompTIA Security+ Certification Exam > SQL Injection vs XSS: Security+ 701 Deep Dive

SQL Injection vs XSS: Security+ 701 Deep Dive

Comparison Cert Sensei Team 2028-01-11 8 min read

SQL Injection targets server-side databases by manipulating queries to steal or modify data, while Cross-Site Scripting (XSS) targets client-side users by executing malicious scripts in their browsers. Understanding these application attacks is critical for the SY0-701 exam, focusing on the distinction between server-side exploitation and client-side execution.

#CompTIA Security+ #application attacks #SQL Injection #XSS #SY0-701

What is the fundamental difference between SQLi and XSS?

When you're studying application attacks for the SY0-701, the first thing you need to nail down is the target. SQL Injection (SQLi) is a server-side attack. The attacker is talking to the database, trying to trick it into dumping user tables or bypassing a login screen. If you see keywords like 'database,' 'backend,' or 'query manipulation,' your mind should immediately go to SQLi.

Cross-Site Scripting (XSS), on the other hand, is a client-side attack. Here, the attacker isn't trying to break into the server; they're using the server as a delivery vehicle to send a malicious script to another user's browser. The target is the end-user, not the database. Think of it this way: SQLi steals data from the company, while XSS steals data (like session cookies) from the customer.

How does SQL Injection actually compromise a database?

SQLi happens when an application takes user input and plugs it directly into a database query without cleaning it first. A classic example you'll see in practice scenarios is the use of a single quote (') to break a string or adding 'OR 1=1 --' to a login field. This effectively tells the database, 'Let me in if the password is correct OR if one equals one,' which is always true.

In a real-world scenario, this can lead to total database exfiltration. An attacker could dump the entire customer list, modify pricing in an e-commerce store, or even gain administrative access to the server. For the Security+ exam, remember that the core vulnerability is a lack of input validation and the failure to separate data from the command.

What are the different types of XSS you need to know?

CompTIA loves to test your ability to distinguish between the three main types of XSS. First, there's Stored XSS (Persistent). This is the most dangerous because the script is saved on the server—like in a comment section or a user profile. Every single person who views that page gets hit by the script automatically.

Then you have Reflected XSS (Non-persistent), where the script is 'reflected' off the web server, usually via a malicious link in an email. The victim clicks the link, and the script executes immediately. Finally, there's DOM-based XSS. This happens entirely in the browser; the server is never even involved in the execution of the script. It manipulates the Document Object Model (DOM) to execute code locally on the victim's machine.

How do you stop these application attacks at the code level?

You can't just hope for the best; you need a technical strategy. To kill SQLi, the gold standard is using parameterized queries (also known as prepared statements). This forces the database to treat user input as data, not as executable code. If an attacker enters 'OR 1=1', the database just looks for a user whose name is literally 'OR 1=1', which fails safely.

For XSS, the key is output encoding and strict input validation. You must treat all user-supplied data as untrusted. By encoding the output, you turn characters like < and > into HTML entities (< and >), meaning the browser displays them as text instead of executing them as a script. Combining these two methods creates a robust defense that stops the majority of common application attacks.

Where does a WAF fit into the defense strategy?

While coding fixes are the best long-term solution, a Web Application Firewall (WAF) is your first line of defense. A WAF operates at Layer 7 (the Application Layer) and inspects incoming HTTP traffic for known attack patterns. It looks for signatures like 'UNION SELECT' or '