Três siglas, duas categorias diferentes da OWASP

Um agrupamento que o título deste curso sugere, e erra

"SQLi, CSRF e XSS" num título só parece descrever três ataques da mesma família. O OWASP Top 10:2025, o ranking oficial atual de riscos de segurança em aplicações web, diz outra coisa. Injeção de SQL e XSS ficam numa mesma categoria, A05:2025 Injection. A página dela cita as duas: "Injection inclui Cross-site Scripting (alta frequência/baixo impacto) com mais de 30 mil CVEs e SQL Injection (baixa frequência/alto impacto) com mais de 14 mil CVEs". O CSRF fica em outro lugar, em A01:2025 Broken Access Control, que lista CWE-352: Cross-Site Request Forgery (CSRF) entre as fraquezas notáveis. Dois dos três ataques dividem um mecanismo; o terceiro não.

O que é injeção, citado

A definição da OWASP: "Uma vulnerabilidade de injeção é uma falha de aplicação que permite que entrada não confiável do usuário seja enviada a um interpretador (por exemplo, um navegador, um banco de dados, a linha de comando) e faz o interpretador executar partes dessa entrada como comandos". Um banco SQL é um interpretador, e um navegador renderizando HTML é outro. SQLi e XSS são o mesmo erro, entrada não confiável chegando a um interpretador e rodando como código, apontado para dois interpretadores diferentes.

O que o CSRF é, então

No CSRF, nenhum interpretador é enganado para rodar comandos injetados. É uma requisição forjada: o navegador da vítima, já autenticado, é levado a mandar uma requisição que a vítima nunca quis mandar. Nada é injetado em ponto nenhum da cadeia. É por isso que a OWASP o põe em controle de acesso. A falha é uma requisição rodando sem a intenção do usuário por trás, não dados não confiáveis lidos como código.

O que este catálogo já cobre, e onde este curso começa

Em "Formulários Rails: form_with", a aula the-authenticity-token-and-csrf cobre o campo escondido que o form_with acrescenta e a falsificação básica que ele impede. Em "Filtros e concerns", skip-before-action-and-the-real-csrf-case cobre o verify_authenticity_token como um before_action herdado, e a exceção deliberada deste app para o callback OAuth do GitHub. Em "ActionView: templates", html-safe-and-escaping cobre o escape padrão do ERB e o .html_safe como uma saída explícita dele, usando o _welcome_modal.html.erb deste app. Nada disso é ensinado de novo aqui.

O que este curso cobre

As aulas 2 e 3 cobrem injeção de SQL, o único ataque deste título que nenhum curso do catálogo cobriu. Elas mostram o mecanismo dela e os padrões de consulta deste app que já são seguros. A aula 4 aprofunda o CSRF: como o token é checado e o que acontece quando não bate. A aula 5 cobre os tipos de XSS e a diferença entre raw e .html_safe. A aula 6 lê a configuração de Content-Security-Policy deste app, que nenhum curso do catálogo citou antes. A aula 7 fecha com um cenário de revisão que usa as três coisas.

Onde isso deixa você

Esses três ataques não são uma coisa só com nomes diferentes. Você vai conhecer o mecanismo de cada um bem o bastante para pô-lo na categoria certa da OWASP. Também vai conhecer o código deste app bem o bastante para dizer o que já está defendido, e contra o quê.