概要
SQL Injection has sat near the top of the OWASP Top 10 for over twenty years. The reason it survives is depressing: developers keep building strings to talk to databases, and string-building plus untrusted input is the recipe. The win condition for the attacker is rarely subtle — they pull every row from your users table, dump password hashes, or write themselves an admin account.
仕組み
SQL injection appears when request input can change the structure or behavior of a database query. The result can be data exposure, authentication bypass, or unintended database changes.
被害範囲
Full read access to every row your application's database user can see — and that user is usually privileged. Often write access too: changing prices, granting admin roles, planting persistent backdoors. In the worst case the attacker chains SQLi into RCE via stacked queries, file writes (`SELECT … INTO OUTFILE`), or PostgreSQL's `COPY` extension.
// what fixvibe checks
What FixVibe checks
FixVibe checks this class with verified-domain active testing that is bounded, non-destructive, and evidence-driven. Public reports describe the affected surface and remediation. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
鉄壁の防御
Use parameterized queries (also called prepared statements) absolutely everywhere. Modern ORMs and query builders do this by default — the bugs creep in when developers reach for raw SQL with template literals. The principle: the SQL string and the data must travel through different channels so the database never re-parses user input as code. As a second layer, give your application's DB user the minimum privileges it needs — read-only roles for read-heavy services, no DDL grants on app users, separate roles for admin operations. As a third layer, use a Web Application Firewall to drop the obvious payloads. None of these alone is enough; together they make exploitation prohibitively expensive.