Como você defende uma aplicação web contra XSS, CSRF e SQL injection?

Os três vêm de misturar entrada não confiável em um contexto confiável. Barre SQL injection com queries parametrizadas, nunca com concatenação de string. Barre XSS com codificação de saída sensível ao contexto, evitando injeção de HTML cru, sanitizando qualquer HTML que você precise renderizar, e com uma Content Security Policy estrita. Barre CSRF com cookies SameSite mais um token por sessão nas requisições que mudam estado, ou um header customizado que um formulário de outro site não consegue definir.

Eu penso neles como um formato só: dado de um usuário termina em algum lugar onde ele é interpretado. No SQL, o interpretador é o banco, então queries parametrizadas ou um query builder que faz bind dos valores resolvem por completo, e não existe motivo aceitável para concatenar uma string. No XSS, o interpretador é o navegador, e o ponto principal é que escapar depende do contexto. O React escapa nós de texto por você, então o risco se concentra nas saídas de emergência: injeção de HTML cru, valores de href que poderiam ser uma URL javascript, e qualquer coisa escrita direto no DOM. Onde um produto genuinamente precisa de HTML do usuário, como um campo de texto rico, eu sanitizo com uma biblioteca de lista de permissões no servidor e adiciono uma CSP estrita como segunda camada, para uma escapada não virar automaticamente um sequestro de conta. O CSRF só se aplica quando o navegador anexa credenciais automaticamente, então SameSite em Lax mata a maior parte, e eu ainda adiciono um token por sessão em qualquer coisa que muda estado. Os cookies ganham httpOnly e Secure como praxe.