Diesel: documento (falta?) risco de injeção de SQL

O diesel escapa automaticamente de variáveis ​​para evitar ataques de injeção de SQL?

sim.

De qualquer forma, seria útil discutir quais medidas são tomadas pelo diesel

Não tenho certeza se devemos ir muito a fundo aqui. A proteção contra ataques de injeção de SQL é praticamente um recurso presumido de qualquer ORM.

quais medidas devem ser tomadas pelo usuário para evitar ataques de injeção de SQL.

Nenhum

Indo encerrar este assunto. Por favor, comente se você ainda acha que há algo acionável a ser feito aqui.

Bem, dada a cotação We achieve this by having Diesel eliminate the possibility of incorrect database interactions at compile time , não ficou claro para mim que Diesel estava fazendo verificações de tempo de execução em cima de verificações de tempo de compilação. Então, com certeza, os ORMs tradicionais devem interromper os ataques de injeção, mas o Diesel é muito diferente dos ORMs que usei.

Eu acho que alguma documentação (uma frase) em algum lugar dizendo que a injeção de SQL é interrompida por meio de identificadores de escape em tempo de execução seria útil.

Mais uma vez, acho que o escape de identificadores e strings (ou usando instruções preparadas, que é o que fazemos) seria presumido de _todos_ ORMs, mas sinta-se à vontade para abrir um PR e podemos discutir as alterações específicas que você gostaria de fazer no documentos.