SQL Injection
SQL injection is a vulnerability where an attacker inserts malicious SQL through an application's input fields to manipulate or extract data from its database — bypassing authentication, reading data they shouldn't see, or deleting records. It happens when user input is concatenated directly into a query instead of being parameterized, and remains one of the OWASP Top 10's most exploited flaws.
The classic example: a login form builds its query as "SELECT * FROM users WHERE username = '" + input + "'". An attacker enters ' OR '1'='1 as the username, and the query becomes true for every row in the table — logging them in as the first user found, no valid password required.
Testing for SQL injection means trying exactly that kind of input in every field that eventually touches a database query: single quotes, comment sequences, boolean payloads, and time-based payloads that deliberately slow the response to confirm a query executed. Automated scanners (sqlmap, Burp Suite) exist specifically for this, but manual testers should still understand the mechanics well enough to try a few payloads by hand.
The fix is almost always parameterized queries or prepared statements — the input is passed as a bound parameter, never concatenated into the SQL string, so the database treats it as data, never as executable code. Input validation helps but isn't sufficient on its own; parameterization is the actual defense.
Example
Vulnerable: "SELECT * FROM users WHERE username = '" + input + "'"
Payload: ' OR '1'='1
Result: SELECT * FROM users WHERE username = '' OR '1'='1' -- matches every rowThe classic authentication-bypass payload, and why string concatenation makes it work.
