React
Explica riesgos de seguridad en interfaces React: XSS, contenido HTML, URLs, secretos, autorización, dependencias y límites de la protección del frontend.
React escapa valores interpolados como texto:
<p>{comment.body}</p>Esto reduce XSS accidental, pero no protege todos los sinks.
dangerouslySetInnerHTML exige contenido sanitizado con una política confiable.
<div dangerouslySetInnerHTML={{ __html: sanitizedHtml }} />No intentes sanitizar con expresiones regulares.
Valida protocolos y destinos antes de usar datos externos en href, src o redirecciones.
Todo código y variable incluida en el bundle puede inspeccionarse. Las credenciales privadas pertenecen al servidor.
Ocultar un botón o una ruta no impide llamar una API. El backend valida identidad, rol y acceso al recurso.
Evita decisiones automáticas sobre almacenamiento sin analizar XSS, CSRF, expiración y arquitectura. Cookies seguras y sesiones requieren configuración del servidor.
Mantén paquetes actualizados y reduce librerías innecesarias. Un componente de terceros ejecuta código dentro de tu aplicación.
React ayuda a representar texto de forma segura, pero la seguridad real atraviesa cliente, servidor, datos y despliegue.
usuario / URL / storage / API
↓ entrada no confiable
validación y normalización
↓
UI React
↓ requests
servidor autoriza y persisteReact protege algunos sinks de texto, pero la seguridad depende de cada frontera.
<p>{userInput}</p>React crea texto, no interpreta tags. Esta protección no aplica cuando el valor entra en otros contextos:
srcdoc o embeds.Escapar para HTML no valida una URL ni una consulta del servidor.
Proceso seguro:
contenido no confiable
↓ parser/sanitizer mantenido
política de tags y atributos
↓
HTML sanitizado
↓ renderSanitiza lo más cerca posible del límite y evita volver a concatenar HTML después. Considera Trusted Types y Content Security Policy en aplicaciones de alto riesgo.
No permitas por defecto:
function safeExternalUrl(value: string): URL | null {
try {
const url = new URL(value);
return ["https:", "http:"].includes(url.protocol) ? url : null;
} catch {
return null;
}
}La política depende del caso. Para imágenes quizá solo HTTPS y dominios permitidos. Para redirects internos, usa rutas relativas o allowlist; evita open redirects.
En enlaces externos con nueva pestaña, revisa rel="noopener noreferrer" según navegadores y política.
if (!canEditProject(session.user, project)) {
throw new ForbiddenError();
}Ocultar un botón no autoriza. Cada loader, API, Action o Server Function valida ownership y rol.
No envíes un campo solo porque “no se muestra”. Props, RSC payloads, JSON, cache y source pueden inspeccionarse. Filtra en servidor el DTO permitido:
return {
id: user.id,
displayName: user.displayName,
};No serialices hashes, secretos, permisos internos completos o datos de otros tenants.
Cualquier variable incorporada al bundle público es visible. Los prefijos como VITE_ o NEXT_PUBLIC_ significan exposición, no cifrado. Secretos permanecen en runtime servidor.
No existe una recomendación universal de storage. Evalúa:
Una cookie HttpOnly reduce lectura desde JavaScript, pero necesita estrategia CSRF. localStorage evita envío automático, pero un XSS puede leerlo. Diseña con especialistas y threat model.
Para mutaciones con cookies:
Framework Actions siguen siendo endpoints y requieren estas protecciones.
Aunque React escape texto, un atacante puede explotar:
innerHTML.javascript: en una integración.Inventaría todos los sinks, no solo JSX.
Minimiza superficie:
Un audit automático no demuestra ausencia de vulnerabilidades.
Una plataforma puede añadir:
La configuración depende de assets, SSR y terceros. CSP con nonces/hashes puede requerir integración del framework.
Nunca confíes únicamente en businessId enviado por cliente. Deriva tenant permitido desde sesión y valida cada consulta:
repository.findOrder({
orderId,
businessId: session.businessId,
});Constraints y políticas de base de datos pueden añadir defensa en profundidad.
No muestres stack traces ni respuestas crudas. No registres:
Usa IDs de correlación y mensajes sanitizados.
Valida en servidor:
No renderices SVG o HTML de usuarios bajo el mismo origen sin políticas estrictas.
Una prueba de componente no cubre seguridad servidor.
Portals, modales y capas de interfaz aplica seguridad y accesibilidad a contenido que escapa de su contenedor DOM.