XSS en React: dangerouslySetInnerHTML no es el único culpable
React escapa por defecto, pero URLs javascript: y libs de markdown lo arruinan. Checklist para apps internas que manejan HTML de usuarios.
OWASP clasifica XSS persistente y reflejado entre riesgos web clásicos; React ayuda escapando JSX pero equipos en PYMES siguen introduciendo vectores con rich text editors, PDF viewers embebidos, y query params renderizados sin sanitizar. Smashing Magazine ha cubierto patrones seguros en SPAs — aplíquelos en portales de clientes y dashboards admin.
Reglas: nunca insertar HTML crudo sin DOMPurify o equivalent
Reglas: nunca insertar HTML crudo sin DOMPurify o equivalente mantenido; validar URLs en href/src contra esquemas permitidos; CSP como red de seguridad cuando alguien olvida sanitizar. Para markdown, use renderer que deshabilite HTML crudo o lo filtre agresivamente.
Apps internas no son "bajo riesgo" — un XSS en portal ERP pu
Apps internas no son "bajo riesgo" — un XSS en portal ERP puede robar sesión de contabilidad y aprobar transferencias. Trate datos de empleados y clientes igual que producción pública en términos de output encoding.
Testing: incluya payloads XSS en tests E2E de formularios críticos; scanners DAST en staging antes de releases mayores. Google Security Blog documenta bypasses de sanitizers obsoletos — mantenga dependencias al día.
React seguro es disciplina de equipo, no feature del framework. Code review debe flaggear dangerouslySetInnerHTML como crypto-mining level sensitivity — permitido con justificación y tests.
Operaciones y ejecución — conecta estrategia con lo que el equipo entrega cada semana.
