---
title: "SQL Injection"
canonical: https://trickest.com/glossary/sql-injection
description: "SQL injection abuses unsanitized input that an application places into a database query, letting an attacker read, modify, or delete data the query was never meant to expose."
---

# SQL Injection

SQL injection (SQLi) happens when an application builds a database query by concatenating user input as text instead of binding it as a parameter. An attacker who controls part of that string can change the query's meaning: break out of a quoted value, append a `UNION SELECT`, or comment out the rest of the statement. The result ranges from dumping entire tables to bypassing authentication to writing files on the database host.

SQLi stays a priority finding because the payoff is direct access to the data the application was built to protect, and because the bug class survives in legacy code and hand-built query strings. Blind variants matter too: when the app returns no error or data, an attacker infers results from boolean responses or time delays, which slows exploitation but does not stop it. The fix is consistent, parameterized queries (prepared statements), with input validation as defense in depth.

SQLi sits among the most-tested risks in [web application security](/glossary/web-application-security) and has held a place in the [OWASP Top Ten](/glossary/owasp-top-ten) for years. It belongs to the same input-abuse family as [command injection](/glossary/command-injection).

In a Trickest workflow you crawl an app for parameters, drive them through [fuzzing](/glossary/fuzzing) with injection payloads, and route candidate hits to a tool like sqlmap for confirmation, all at scale across many hosts.

---
_Markdown source of https://trickest.com/glossary/sql-injection._