Glossary of Terms

A category of attack in which an attacker inserts malicious code into a data stream that an application processes. The application, failing to validate or sanitize the input, interprets the injected content as executable code rather than data. Code injection vulnerabilities arise from poor programming practices — particularly when applications accept user input without checking it. SQL injection, HTML injection, XML injection, and LDAP injection are all forms of code injection targeting different technologies.

A type of code injection attack that targets applications using Structured Query Language (SQL) to interact with databases. The attacker inserts malicious SQL commands into an input field that the application passes to the database. If the application does not properly validate the input, the database executes the attacker's commands as part of the intended query. SQL injection can be used to bypass authentication, retrieve unauthorized data, modify records, delete data, and in some configurations execute operating system commands.

The standard language used to create, read, update, and delete data in relational database management systems. SQL commands include SELECT (read data), INSERT (add records), UPDATE (modify records), DELETE (remove records), and DROP (delete tables or databases). SQL injection attacks exploit the fact that the same language used to query data can also be used to destroy it or extract unauthorized information — when the attacker's input is interpreted as SQL commands.

The process of checking that data submitted by a user or external source conforms to expected format, type, length, and content before the application processes it. Input validation for SQL injection prevention means rejecting or escaping characters that have special meaning in SQL — apostrophes, semicolons, comment markers, and SQL keywords — before they reach the database query. Effective input validation treats all external input as potentially hostile and applies strict rules about what is acceptable.

A database query technique that separates the SQL structure from the user-supplied data. The developer defines the query template with placeholders first — for example, SELECT * FROM users WHERE name = ? — then binds user input to those placeholders as pure data values. The database engine treats the bound values as literal data, never as SQL code. This means even if the user enters SQL syntax, it cannot be interpreted as commands. Parameterized queries are the most effective single control against SQL injection.

The vulnerable programming practice of constructing SQL queries by directly appending user input to a SQL string. For example: query = "SELECT * FROM users WHERE name = '" + userInput + "'". If userInput contains SQL syntax — such as an apostrophe or the OR 1=1 clause — the database engine executes that syntax as part of the query. String concatenation is the root cause of most SQL injection vulnerabilities. The fix is to replace it with parameterized queries.

A classic SQL injection payload that appends OR '1'='1' (or OR 1=1) to a WHERE clause, making the condition always evaluate to true. Because 1 always equals 1, the WHERE clause matches every row in the table rather than the intended filtered subset. This pattern is used to retrieve all records from a table regardless of the intended filter. Seeing OR 1=1 or equivalent tautologies in database logs is a strong indicator of a SQL injection attempt in progress.

A pre-written SQL routine stored in the database that an application calls by name rather than constructing SQL queries dynamically. When implemented correctly, stored procedures can reduce SQL injection risk by limiting what SQL operations the application can invoke — the application calls a procedure name with parameters rather than building arbitrary SQL strings. However, stored procedures that internally build dynamic SQL from parameters remain vulnerable unless they also use parameterized queries internally.

The security principle that each database account should be granted only the permissions it actually needs for its function — and no more. A web application that only needs to read customer records should use a database account with SELECT-only permission, not an account with INSERT, UPDATE, DELETE, or DROP privileges. If the application is compromised via SQL injection, the attacker is limited to whatever permissions the compromised account holds. Least privilege does not prevent injection but dramatically limits its impact.

A security device or service that monitors, filters, and blocks HTTP traffic to and from a web application. A WAF can detect and block common SQL injection patterns — recognizing payloads such as OR 1=1, UNION SELECT, DROP TABLE, and comment sequences (-- and /*) — before they reach the application. WAFs provide a defensive layer at the network boundary but are not a substitute for proper parameterized queries in application code. An attacker may use obfuscation techniques to evade WAF signatures that would not fool a properly parameterized query.

A SQL injection technique that exploits a login form to gain access without valid credentials. By injecting SQL into the username or password field, the attacker alters the authentication query so it returns a true result regardless of the password entered. For example, injecting ' OR '1'='1'-- into the username field can make the query ignore the password check entirely. Authentication bypass is one of the most impactful SQL injection outcomes — it grants access to any account, including administrator accounts, without knowing any credentials.

An advanced SQL injection technique that appends a UNION SELECT statement to the original query, combining its results with data from a different table. For example, injecting ' UNION SELECT username, password FROM admin_users-- adds the contents of the admin_users table to the query results. UNION-based injection is used to extract data from tables other than the one the original query targeted, allowing attackers to pivot through the entire database schema.