SQL Injection Defense: Least Privilege and Defense in Depth

Parameterized queries are the primary control against SQL injection. They address the root cause. Every other measure described here assumes the primary control may sometimes fail, whether due to a missed code path, a new feature developed without security review, or a third-party library with a vulnerability. Defense in depth reduces the damage from a successful injection that bypasses the primary control.

Database Account Permissions

The application connects to the database with a database account. That account has privileges granted to it. An injected query runs with those same privileges, no more.

A web application that only reads and writes its own tables does not need:

• SELECT on tables belonging to other applications on the same database server
• INSERT, UPDATE, or DELETE on tables the application only reads
• DROP, ALTER, or CREATE privileges on any table
• FILE privileges (MySQL's LOAD DATA and INTO OUTFILE operate under the database account's OS permissions)
• EXECUTE on stored procedures not called by the application

An application account with only the SELECT and DML privileges it actually uses limits an injected query to what the application itself could do. The attacker can read and write application data but cannot drop tables, read the mysql.user system table, or write files to the filesystem.

Separate read and write accounts provide additional granularity. Endpoints that only read data connect with a read-only account. An injection in a search endpoint cannot issue INSERT or UPDATE statements if the account has no write privileges.

Query Allowlisting with Application Firewalls

A database activity monitor or application-level firewall can intercept queries before they reach the database and compare them against a set of known-good query templates. A query that does not match any known template is rejected or flagged.

This approach requires building a catalog of all queries the application legitimately issues, which is operationally significant for large applications. The catalog must be kept current as the application changes. False positives block legitimate queries. Despite operational cost, allowlisting is the only control that can catch injection in code paths missed by parameterization review.

Error Suppression

Database errors must not reach the client. Error messages aid diagnosis during development but give an attacker information about database schema, software versions, and query structure. In production, all database exceptions should be caught and replaced with a generic response. Detailed errors are written to internal logs accessible only to operations staff.

This does not prevent injection. It removes the error-based extraction channel, forcing any injection to rely on blind techniques, which are slower and more detectable.

WAF Limitations

Web application firewalls that inspect HTTP request parameters for SQL keywords provide partial detection. They do not understand application context and generate false positives on legitimate input containing SQL keywords. Bypass techniques (encoding, fragmentation, comment insertion, case variation) exist for most WAF rule sets. A WAF is a detection layer, not a prevention layer. It should not be used as a substitute for parameterized queries in the application code.