[friendzis]

> SQL injection attacks plagued the industry for decades precisely because the initial format didn't think through how to escape queries.

No. SQL injection vulnerabilities plagued the industry for decades, as opposed to months/years, because developers thought they can take input in one format, "escape" it enough, sprinkle with addslashes and things will work. And apparently we still teach this even when we have decades of experience that escaping does not work. XSS is just a different side of the same coin - pretending that one can simply pipe strings between languages.

You have to speak the language. Good luck getting LLM to respond to tokens deterministically. On top of escaping being a flaky solution in itself you now have an engine that is flaky in parsing escapes.

[Jensson]

> because developers thought they can take input in one format, "escape" it enough, sprinkle with addslashes and things will work

But that is exactly what the solution is, you escape user strings, there is no other solution to the problem. Either you do it yourself or you use a library to do it, but the end result is the same, I'm not sure why you think this is impossible to do when it has been done successfully for decades.

The problem is that many fail to escape strings correctly, not that it is impossible to do.

[friendzis]

Escaping/sanitizing is required when providing "command+data" inputs to external engines. It's error prone. One needs rigorous escaping done just before the output. Multiple escapes can clash.

> But that is exactly what the solution is, you escape user strings, there is no other solution to the problem

The correct way is to use interfaces that allow separation of command and data inputs. With SQL prepared statements are used. With HTTP data is put in request body or at least after the ?. With HTML data URLs are used. And so on.

> The problem is that many fail to escape strings correctly, not that it is impossible to do.

I really don't want to argue whether escaping correctly is possible at all. Every possible substring sequence, escaping attempts included, that can be interpreted as command by the interpreting system must be accounted for. I would rather avoid the problem altogether, if possible.

[stefan_]

No, escaping is precisely not what you do. Escaping is the hack you add because you didn't consider separating code and data in the first place.

Do not offer an API that mixes these two things.

[blowski]

What about parameterised queries?