Defense-in-depth against SQL injection

WHAT THIS TESTS Whether you treat security as layered controls that contain impact, not a single silver bullet, and can name database-level mitigations beyond the application layer.

WHY IT MATTERS Parameterized queries are the correct primary defense, but real systems have legacy code, dynamic SQL for reports, or a single overlooked query. Defense in depth ensures one failure does not hand an attacker the whole database.

A GOOD ANSWER COVERS Apply least privilege so the application account can only touch the tables and verbs it needs; an injection then cannot read the credentials table or run DROP. Use stored procedures and restricted views as the only interface, so even injected input runs within a constrained surface. Enforce strict input validation and allowlisting for values that cannot be parameterized, such as column or table names in dynamic SQL, and use proper escaping when dynamic SQL is unavoidable. Add row-level security where appropriate. Operationally, monitor and log queries, deploy a database activity monitor or firewall to flag anomalous patterns like sudden UNION SELECTs, and alert on error spikes. Disable verbose database error messages to clients so attackers cannot fingerprint the schema.

COMMON WRONG ANSWERS Naming only parameterized queries, suggesting blacklisting bad strings (easily bypassed), or relying solely on a web application firewall while leaving the database account omnipotent.

LIKELY FOLLOW-UPS Why allowlisting beats blacklisting; how stored procedures can still be injectable if they build dynamic SQL; least privilege limiting second-order injection.

ONE CONCRETE EXAMPLE An app overlooks parameterization on one search field. Because its database account holds only SELECT on two tables, the attacker can read those rows but cannot reach the users table, alter schema, or escalate, and the activity monitor flags the unusual UNION query for investigation, turning a potential full breach into a contained, detected incident.