¿Cómo defiendes una aplicación web frente a XSS, CSRF e inyección SQL?

Las tres vienen de mezclar entrada no confiable con un contexto de confianza. Detén la inyección SQL con consultas parametrizadas, nunca con concatenación de cadenas. Detén el XSS con codificación de salida según el contexto, evitando inyectar HTML crudo, saneando cualquier HTML que tengas que renderizar y con una Content Security Policy estricta. Detén el CSRF con cookies SameSite más un token por sesión en las peticiones que cambian estado, o con una cabecera personalizada que un formulario de otro sitio no puede fijar.

Los veo como una sola forma: datos de un usuario acaban en un sitio donde se interpretan. Para SQL, el intérprete es la base de datos, así que las consultas parametrizadas o un constructor de consultas que enlace valores lo resuelven por completo, y no hay motivo aceptable para concatenar una cadena. Para XSS, el intérprete es el navegador, y la clave es que escapar depende del contexto. React escapa los nodos de texto por ti, así que el riesgo se concentra en las vías de escape: inyección de HTML crudo, valores de href que podrían ser una URL javascript, y cualquier cosa escrita directamente en el DOM. Cuando un producto necesita de verdad HTML del usuario, como un campo de texto enriquecido, saneo con una librería de lista de permitidos en el servidor y añado una CSP estricta como segunda capa para que un descuido no sea automáticamente el robo de una cuenta. El CSRF solo aplica cuando el navegador adjunta credenciales de forma automática, así que SameSite en Lax mata casi todo, y aun así añado un token por sesión en cualquier cosa que cambie estado. Las cookies llevan httpOnly y Secure por norma.