document (lack of?) risk of SQL injection

[astraw]

Does diesel automatically escape variables to prevent SQL injection attacks?

I see escape_identifier for the postgres RawConnection and indeed I was apparently unable to hijack my diesel-based interactions with Postgres. That said, I'm not a seasoned attacker, nor did I try with sqlite.

I also found a quote claiming that SQL injection attacks are stopped.

Either way, it would be helpful to discuss what measures are taken by diesel and what measures should be taken by the user to prevent SQL injection attacks.

[sgrif]

Does diesel automatically escape variables to prevent SQL injection attacks?

Yes.

Either way, it would be helpful to discuss what measures are taken by diesel

I'm not sure we should go too in depth here. Protection from SQL injection attacks is pretty much an assumed feature of any ORM.

what measures should be taken by the user to prevent SQL injection attacks.

None

[sgrif]

Going to close this issue. Please do comment if you still think that there is something actionable to be done here.

[astraw]

Well given the quote We achieve this by having Diesel eliminate the possibility of incorrect database interactions at compile time it wasn't clear to me that Diesel was doing runtime checking on top of compile time checks. So, sure, traditional ORMs should stop injection attacks, but Diesel is very different from ORMs I've used.

I do think that some documentation (one sentence) somewhere saying that SQL injection is stopped via escaping identifiers at runtime would be useful.

[sgrif]

Again, I think that escaping identifiers and strings (or using prepared statements, which is what we do) would be assumed of all ORMs, but feel free to open a PR and we can discuss the specific changes you'd like to make to the docs.