(some of) my extant site protections involve pattern matching on the raw strings that comprise GET and POST data. Traffic from IP addresses deemed suspect get a 418 response rather than any page code being executed, and that IP is immediately and permanently blocked (the internet is vast; what’s the loss of a single firefly)
What about complementary blocks based on pattern matching of unsafe/unexpected queries used in building a site? A per-query regex which the query is compared against, and any fail triggers blocks the same way (I’d suggest an audit only mode during development to proof query variations). Potentially even a per-result-shape could be similarly compared, though this would be more complex and incur more load.
e.g.
^(SELECT * FROM table1 WHERE field1 = )('[^']{0,20}')( ORDER BY field2;)$
Expected query: SELECT * FROM table1 WHERE field1 = 'value123!' ORDER BY field2;
But not: SELECT * FROM table1 WHERE field1 = '' OR 1=1--value123!' ORDER BY field2;
And
^(SELECT * FROM table1 WHERE field1 = )(-{0,1}[0-9]{1,6})( ORDER BY field2;)$
Expected query: SELECT * FROM table1 WHERE field1 = 0 ORDER BY field2;
But not: SELECT * FROM table1 WHERE field1 = 0 OR 1=1 ORDER BY field2;
Obviously these are simple examples, care would need to be taken with exact acceptable values in the regex, and it incurs ongoing developer cost in writing regexes for each query.
Also, these were written in under 5 minutes so are very rudimentary and unconsidered.