SQLi is so Last

The talk asks why SQL injection keeps appearing despite prepared statements and ORMs. The speaker argues that prepared statements do not help if an attacker steals database credentials or finds a bug elsewhere, and that some ORMs have had injection flaws too. A core problem is that applications often connect as a powerful database role that can run arbitrary SQL.

The proposed remedy treats the database as an API. The application role receives execute rights only on security-definer functions that perform fixed operations, with row-level limits where needed. A stateless JWT, validated inside Postgres by an extension, lets the database itself decide who is calling rather than trusting the application server. A profile-update example shows the pattern end to end.

The speaker is candid about limits. Exposing the database directly is possible but largely untested, and a stored procedure that uses dynamic execute can itself be injectable, so static analysis and restricted roles remain important. Greenfield projects suit this best, though existing systems can migrate gradually. The takeaway is to shrink what a compromised query can reach rather than rely on one control.