Respuesta rápida: CORS, CSRF y CSP no son tres nombres para el mismo problema. CORS es un mecanismo del navegador, basado en encabezados HTTP, que determina cuándo el código de un origen puede leer una respuesta de otro origen. CSRF es un ataque en el que se induce al navegador de la víctima a enviar una solicitud autenticada que el usuario no pretendía realizar. CSP es una política enviada por un sitio al navegador para limitar qué recursos y código puede cargar o ejecutar una página. En la práctica: un problema para leer una API desde otro origen apunta a CORS; una acción no deseada realizada con la sesión del usuario apunta a CSRF; la ejecución o carga de un script, frame o recurso no autorizado apunta a CSP.
Por qué CORS, CSRF y CSP se confunden
Los tres aparecen en seguridad web, implican decisiones del navegador y suelen surgir durante la depuración del front-end. Además, todos pueden mencionar conceptos como origen, encabezados HTTP y recursos externos. La similitud termina ahí. Cada uno responde a una pregunta distinta y actúa en una dirección diferente del flujo.
Para CORS, la pregunta es si el navegador puede exponer al JavaScript de un origen una respuesta recibida desde otro. Para CSRF, la pregunta es si un sitio controlado por un atacante puede provocar una acción en el servidor objetivo usando credenciales que el navegador envía automáticamente, como cookies de sesión. Para CSP, la pregunta es qué tiene permitido ejecutar, solicitar o incrustar el documento ya cargado.
Matriz: CORS vs. CSRF vs. CSP
| Aspecto | CORS | CSRF | CSP |
|---|---|---|---|
| Qué es | Mecanismo de intercambio entre orígenes basado en encabezados HTTP | Ataque de falsificación de solicitudes en un contexto autenticado | Política de seguridad de contenido aplicada por el navegador |
| Pregunta central | ¿Puede este JavaScript leer la respuesta de ese otro origen? | ¿Puede otro sitio hacer que el navegador del usuario ejecute una acción autenticada? | ¿Qué recursos y formas de ejecución puede usar esta página? |
| Capa principal | Navegador y respuesta del servidor que entrega el recurso | Aplicación y servidor que reciben acciones autenticadas | Navegador siguiendo la política declarada por el sitio |
| Problema típico | Fetch o XMLHttpRequest bloqueado por la política de origen | POST, PUT, PATCH o DELETE no deseado usando la sesión de la víctima | Ejecución de script inyectado, carga de recurso no autorizado o embedding no deseado |
| Controles comunes | Access-Control-Allow-Origin, preflight, métodos y encabezados permitidos, credenciales | Token anti-CSRF, SameSite, validación de Origin o Referer, Fetch Metadata, encabezados personalizados | Content-Security-Policy con directivas como script-src, default-src, connect-src y frame-ancestors |
| Qué no sustituye | Autenticación, autorización y protección contra CSRF | Validación de autorización, corrección de XSS y política de carga de recursos | Sanitización de entradas, autorización, CORS o protección contra CSRF |
| Señal de depuración | Error de CORS en la consola, preflight OPTIONS o respuesta no expuesta al script | Una acción ocurre sin intención del usuario mientras ya está autenticado | La consola informa una violación de Content Security Policy o una directiva bloquea un recurso |
CORS: permiso para leer entre orígenes
La política del mismo origen restringe cómo un documento o script de un origen interactúa con recursos de otro. Un origen se define por la combinación de esquema, host y puerto. CORS, sigla de Cross-Origin Resource Sharing, permite que el servidor indique al navegador qué otros orígenes pueden acceder a una respuesta en un contexto cross-origin.
El encabezado más conocido es Access-Control-Allow-Origin. Según la solicitud, el navegador puede enviar primero un preflight con el método OPTIONS para preguntar qué métodos y encabezados están permitidos. Si la respuesta no satisface la política, JavaScript no recibe acceso normal al contenido de la respuesta.
La distinción clave es que CORS es principalmente una regla sobre el navegador compartiendo una respuesta con el código que hizo la llamada. No es un firewall del servidor y no sustituye la autenticación ni la autorización. Los clientes fuera del navegador, como servicios backend y herramientas HTTP, no dependen del control CORS del navegador para decidir si pueden realizar una solicitud.
Por qué un error de CORS no significa que la solicitud nunca llegó al servidor
Algunas solicitudes llamadas simples pueden enviarse sin preflight, incluidos determinados GET, HEAD y POST con encabezados y tipos de contenido limitados. El servidor debe seguir procesándolas de forma segura. Si el origen no está autorizado por CORS, el navegador puede ocultar la respuesta al JavaScript controlado por el atacante, pero eso no deshace un efecto secundario que el servidor ya haya ejecutado. Esta es una razón por la que CORS no debe tratarse como una defensa contra CSRF.
Las credenciales añaden otra fuente frecuente de confusión. Cuando una respuesta CORS se comparte para una solicitud que incluye credenciales, la configuración debe ser más restrictiva. Un comodín en Access-Control-Allow-Origin no funciona como permiso genérico para respuestas con credenciales, y las políticas de cookies de terceros siguen aplicándose.
CSRF: el problema es la acción falsificada, no leer la respuesta
Cross-Site Request Forgery explota el hecho de que los navegadores pueden adjuntar credenciales automáticamente a una solicitud, especialmente cookies de sesión. Un atacante prepara una página o flujo que hace que el navegador de la víctima envíe una solicitud a una aplicación donde la víctima ya está autenticada. Si el servidor acepta la solicitud solo porque la cookie de sesión está presente, una acción puede ocurrir sin intención del usuario.
El atacante no necesita necesariamente leer la respuesta para que el ataque tenga éxito. Si una operación como cambiar un correo electrónico, añadir una clave, modificar una configuración o iniciar una transacción se completa en el servidor, bloquear la lectura de la respuesta mediante CORS no corrige la debilidad.
Defensas que realmente corresponden al problema de CSRF
- Token anti-CSRF: las aplicaciones con estado pueden usar el patrón de token sincronizado, en el que el servidor emite un valor secreto e impredecible y lo valida en solicitudes que cambian estado.
- Cookies SameSite: reducen el envío de cookies en muchos contextos cross-site. OWASP trata SameSite como una capa importante, pero no como un sustituto universal de los controles anti-CSRF.
- Verificación de origen: el servidor puede validar Origin y, en escenarios de fallback, Referer, comparando el origen de la solicitud con el destino esperado.
- Fetch Metadata: encabezados como Sec-Fetch-Site aportan contexto adicional que puede ayudar a rechazar solicitudes cross-site sospechosas.
- Encabezado personalizado en APIs: en arquitecturas AJAX o API, exigir un encabezado que un sitio externo no puede añadir como solicitud simple puede formar parte de la defensa, siempre que la política CORS sea restrictiva y la API no acepte además tipos de contenido simples inseguros como alternativa.
Las defensas correctas dependen de la arquitectura. Un formulario tradicional, una SPA que usa cookies y una API que usa tokens explícitos tienen superficies de ataque diferentes. También es importante evitar cambios de estado mediante solicitudes GET, porque los métodos considerados seguros reciben un tratamiento especial en navegadores y políticas de cookies.
CSP: restringir lo que la página puede cargar y ejecutar
Content Security Policy se entrega principalmente mediante el encabezado de respuesta Content-Security-Policy. La política contiene directivas que indican al navegador qué fuentes y comportamientos están permitidos. script-src controla fuentes y formas permitidas de ejecución de JavaScript; style-src hace lo mismo con estilos; img-src controla imágenes; connect-src restringe destinos de conexiones iniciadas por scripts; frame-ancestors controla quién puede incrustar la página.
Uno de los usos principales de CSP es reducir el riesgo y el impacto de XSS. Una política estricta puede bloquear scripts inline no autorizados, manejadores de eventos inline, URLs con esquema JavaScript y fuentes externas que no estén permitidas. Los nonces o hashes pueden autorizar scripts específicos sin habilitar ampliamente la ejecución inline.
CSP es una defensa en profundidad. No hace seguro insertar entradas sin sanitizar en HTML y no sustituye el encoding ni la sanitización. Tampoco decide si un servidor remoto debe compartir su respuesta con otro origen, que es CORS, ni verifica si una acción autenticada fue realmente solicitada por el usuario, que es el problema de CSRF.
Por qué connect-src tampoco convierte CSP en CORS
connect-src puede impedir que la página actual use fetch, XMLHttpRequest, WebSocket y conexiones relacionadas hacia destinos no autorizados. Esto puede parecer CORS a primera vista, pero la dirección es diferente. CSP es una regla declarada por el propio sitio de la página para restringir el comportamiento de esa página. CORS es la respuesta del servidor de destino que indica al navegador si una respuesta cross-origin puede exponerse al código que hizo la llamada. Ambos controles pueden aplicarse a la misma solicitud.
Tres mini escenarios para identificar el concepto correcto
Escenario 1: la SPA llama a la API y la consola muestra un bloqueo por origen
El front-end en https://app.example llama a https://api.example. La API funciona cuando se prueba con una herramienta HTTP, pero el navegador no expone la respuesta a JavaScript. El primer concepto que se debe investigar es CORS: Access-Control-Allow-Origin, preflight, métodos, encabezados y credenciales. La autenticación de la API sigue siendo una cuestión separada.
Escenario 2: un sitio externo provoca el cambio de correo de un usuario conectado
La aplicación usa una cookie de sesión. El usuario visita un sitio malicioso que puede enviar una solicitud compatible con formulario al endpoint de cambio de correo. La respuesta no necesita ser legible. Si el servidor realiza el cambio simplemente porque recibió la cookie, el problema es CSRF. La defensa debe validar la intención, por ejemplo con un token, una configuración SameSite adecuada, verificación de origen o controles equivalentes para la arquitectura.
Escenario 3: un campo de comentarios permite ejecutar JavaScript inyectado
La vulnerabilidad principal es XSS, y CSP puede reducir la capacidad del payload para ejecutar o cargar código no autorizado. La corrección de la causa raíz sigue siendo tratar de forma segura la entrada y la salida. Una política estricta actúa como defensa en profundidad. Configurar CORS no corrige la inyección, y un token anti-CSRF no detiene JavaScript que ya se está ejecutando dentro del origen confiable.
Cómo elegir rápidamente qué defensa investigar
- Si el fallo es leer una respuesta cross-origin en el navegador, investigue CORS y la política del mismo origen.
- Si el fallo es que una acción autenticada ocurra sin intención del usuario, investigue CSRF y cómo el servidor valida las solicitudes que cambian estado.
- Si el fallo es que código o un recurso no autorizado se ejecute, cargue o sea incrustado, investigue CSP y, si existe inyección, la causa subyacente de XSS.
- Si aparece más de un problema en el mismo flujo, trate cada capa por separado. Es común que una SPA necesite CORS correcto, protección anti-CSRF por usar cookies y una CSP estricta al mismo tiempo.
Errores de configuración que mantienen la confusión
- Abrir Access-Control-Allow-Origin ampliamente para resolver cualquier error: puede solucionar un síntoma de integración, pero puede exponer respuestas a orígenes innecesarios y no crea autorización de aplicación.
- Tratar el preflight como barrera anti-CSRF: las solicitudes simples existen en parte por compatibilidad con formas históricas de envío cross-site. El endpoint necesita sus propios controles.
- Usar CSP como sustituto de la sanitización: CSP reduce vectores de ejecución, pero MDN recomienda tratarla como parte de una estrategia más amplia contra XSS.
- Tratar Origin como identidad del usuario: el origen ayuda en políticas del navegador y verificaciones anti-CSRF, pero autenticación y autorización siguen necesitando controles propios en el servidor.
- Olvidar que XSS puede debilitar las defensas contra CSRF: código malicioso ejecutándose dentro del origen de la aplicación puede, en muchos escenarios, leer tokens disponibles para JavaScript y enviar solicitudes como si fuera la propia aplicación.
Una forma breve de recordar la diferencia
CORS trata de compartir respuestas entre orígenes. CSRF trata de falsificar acciones autenticadas. CSP trata de limitar el comportamiento y la carga de recursos de la página. La defensa correcta depende de la pregunta correcta: quién intenta leer, quién intenta actuar y qué tiene permitido ejecutar o cargar la página.
