Glosario
Qué es CORS: cómo funciona y qué expone una mala configuración
CORS controla si el JavaScript de otro origen puede leer las respuestas de tu API. Una mala configuración permisiva deja que un tercero lea datos de un usuario con sesión iniciada. Cómo funciona y los ajustes seguros (lista de permitidos).
"Añadí Access-Control-Allow-Origin y la API funcionó, ¿es seguro?" CORS no es "añadirlo y listo"; lo importante es acotar a quién permites. Aquí tienes cómo funciona y cómo configurarlo de forma segura (sin pasos de ataque).
Primero, cómo funciona
Los navegadores aplican una política del mismo origen: el JS de otro origen no puede leer libremente las respuestas de otro sitio. CORS existe para abrir esa excepción solo a las partes que el servidor permite explícitamente.
| Encabezado de respuesta | Significado |
|---|---|
Access-Control-Allow-Origin | Qué orígenes pueden leer la respuesta |
Access-Control-Allow-Credentials | Si se permiten solicitudes con credenciales (cookies) |
Access-Control-Allow-Methods / -Headers | Qué métodos/encabezados HTTP se permiten |
El punto clave: CORS está del lado de "relajar la restricción". Relájala mal y datos que no deberían poder leerse se vuelven legibles para terceros.
Qué hace peligroso un ajuste
Ajustes peligrosos (comunes)
- Reflejar el Origin de la solicitud como permitido
Access-Control-Allow-Origin: *junto con permitir credenciales- Abrir APIs ampliamente de origen cruzado que no lo necesitan
Ajustes seguros
- Una lista de permitidos (solo orígenes fijos y de confianza)
- Denegar por defecto todo lo demás
- Para solicitudes con credenciales, un origen concreto, no
*
Los fundamentos de un ajuste seguro
Usa una lista de permitidos (lo más importante)
No reflejes el Origin a ciegas
Origin de la solicitud directamente en Access-Control-Allow-Origin. Devuélvelo solo cuando coincida con la lista de permitidos.Nunca uses * con credenciales
Access-Control-Allow-Origin: * con Allow-Credentials: true. Nombra en su lugar un origen concreto.Minimiza lo que abres
La opinión de este sitio: CORS es 'cómo relajas', no 'la defensa' — acota a quién abres
Un error común es pensar que "añadir encabezados CORS lo hace seguro". Es lo contrario: CORS relaja la restricción del navegador. Así que el truco no es "cómo lo añades", sino "minimizar a quién, y hasta dónde, abres." En este sitio separamos los datos que es correcto leer desde fuera de los que no, y recomendamos denegar por defecto, con una lista de permitidos que abra solo las excepciones. Ten en cuenta que XSS (que rompe la premisa de lectura) y CSRF (que apunta a cambios de estado) son fallos distintos: CORS por sí solo no lo cubre todo.
Sigue leyendo
- Glosario: Qué es XSS · Qué es CSRF
- Comprueba: Verificador de encabezados de seguridad
FAQ
Q¿Para qué sirve CORS?
Los navegadores aplican una política del mismo origen: el JavaScript de un origen (sitio) no puede leer libremente las respuestas de otro sitio. CORS (Cross-Origin Resource Sharing) es cómo un servidor abre esa excepción, pero solo a las partes que permite explícitamente. Encabezados de respuesta como Access-Control-Allow-Origin declaran qué orígenes pueden leer la respuesta.
Q¿Qué expone una mala configuración de CORS?
Unos permisos demasiado laxos pueden dejar que el sitio de un atacante lea, vía JavaScript, las respuestas de la API de un usuario con sesión iniciada. Casos clásicos: reflejar como permitido el Origin de la solicitud, o poner Access-Control-Allow-Origin a * permitiendo además credenciales (cookies). El resultado es que datos personales o tokens pueden llegar a un tercero.
Q¿Cuál es la base de un ajuste seguro?
Una lista de permitidos. Permite solo orígenes de confianza decididos de antemano y deniega el resto (denegar por defecto). No reflejes a ciegas el Origin de la solicitud. Para solicitudes con credenciales, no uses * en Access-Control-Allow-Origin: nombra un origen concreto. Y expón solo los endpoints que de verdad necesiten ser de origen cruzado.