PSA: If you want to fix security with better documentation be aware that it almost certainly won't work.
-
-
prep. stmts were slow with mysql (still true?) and the recommended way to deploy postgresql means disabling them https://pgbouncer.github.io/faq.html
-
This seems like an utterly broken implementation architecture. There's no reason the DB server of proxy ever needs to see prepared stmts.
-
A proper API does them entirely client-side and sends standard SQL (filling in parameters with proper escaping) over the wire.
-
Ah, you mean client-side escaping, not server-side prepared statements that save server resources (parsing, permissions, query planning).
-
I don't really care how it's implemented under the hood. Important part is that the app never be allowed to write queries as strings.
-
Server-side prepared statements are an optimization choice (maybe a tradeoff) whereas how API looks to the app is a matter of secure design.
-
Do you propose, e.g., that the custom SQL API check that the SQL string does not contain value literals, only table/column/function names?
-
I propose APIs that do not accept value literals anywhere in the query string, only as parameters.
- 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.