JavaScript
Explica la política same-origin, el funcionamiento de CORS y las credenciales para entender qué solicitudes permite el navegador y por qué.
La limita cómo un documento o script puede leer recursos de otro origen. es un protocolo mediante headers HTTP que permite al servidor autorizar ciertas lecturas cross-origin desde navegadores.
origin = scheme + host + porthttps://example.com
https://example.com:443Normalmente representan el mismo origen por el puerto predeterminado.
http://example.com
https://example.comSon distintos por scheme.
https://api.example.com
https://app.example.comSon distintos por host, aunque puedan considerarse same-site en otros contextos.
Sin esta barrera, una página maliciosa podría abrir servicios donde ya tienes sesión y leer información privada directamente.
La política restringe principalmente la lectura y acceso programático. Enviar ciertas solicitudes cross-origin siempre ha sido posible mediante elementos o formularios, por lo que también existen riesgos como CSRF.
Access-Control-Allow-Origin: https://app.example.comEste header indica qué origen puede leer la respuesta desde JavaScript del navegador.
No demuestra que la persona esté autenticada ni autorizada para el recurso. El servidor debe validar sesión, token y permisos por separado.
Algunas solicitudes pueden enviarse sin preflight cuando cumplen condiciones limitadas de método, headers y content type.
El navegador añade:
Origin: https://app.example.comEl servidor puede responder:
Access-Control-Allow-Origin: https://app.example.comSi falta autorización CORS, la red puede haber ocurrido, pero JavaScript no puede leer la respuesta.
Para solicitudes no simples, el navegador puede enviar primero:
OPTIONS /api/products
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization, content-typeRespuesta:
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Authorization, Content-TypeSolo después se envía la solicitud real si la política lo permite.
Entre otros:
No intentes evitar preflight sacrificando contratos correctos sin medir una necesidad real.
fetch("https://api.example.com/account", {
credentials: "include",
});El servidor debe responder con un origen explícito:
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: trueNo puede utilizar * junto con credenciales.
Cuando el servidor refleja orígenes permitidos:
Vary: Originindica a caches que la respuesta puede cambiar según el header Origin. Omitirlo puede mezclar respuestas CORS entre consumidores.
No es válido esperar:
Access-Control-Allow-Origin: https://a.com, https://b.comEl servidor compara el Origin contra una allowlist y responde con uno autorizado o no añade el header.
JavaScript solo puede leer ciertos headers de respuesta por defecto.
Access-Control-Expose-Headers: X-Request-IdDespués:
response.headers.get("X-Request-Id");Access-Control-Max-Age: 600Permite al navegador reutilizar temporalmente el resultado, sujeto a límites propios.
fetch(url, { mode: "no-cors" });Produce una respuesta opaca que JavaScript no puede inspeccionar normalmente. Se utiliza en casos específicos como ciertos recursos para service workers; no desbloquea una API.
Una solicitud servidor-a-servidor no está restringida por la same-origin policy del navegador, aunque sigue necesitando autenticación, autorización y validación.
Por eso “funciona en Postman pero no en el navegador” puede indicar CORS, pero también configuración de cookies, redirects o TLS.
CORS no impide que un navegador envíe todas las solicitudes cross-site posibles. Si la autenticación usa cookies automáticas, protege acciones contra CSRF.
Medidas:
Una página puede cargar imágenes, scripts, estilos o iframes cross-origin bajo reglas específicas. Poder cargar no significa poder leer sus datos internos mediante JavaScript.
Para comunicación controlada entre ventanas de orígenes distintos:
otherWindow.postMessage(message, targetOrigin);Al recibir:
window.addEventListener("message", (event) => {
if (event.origin !== "https://trusted.example") {
return;
}
const message = parseMessage(event.data);
});Nunca uses * como targetOrigin para información sensible ni confíes en event.data sin validar.
CORS protege al usuario del navegador, no al servidor frente a URLs controladas por usuarios.
Si un backend hace fetch a una URL recibida, debe protegerse contra SSRF mediante allowlists, resolución segura, bloqueo de redes internas y controles de redirects.
Content Security Policy limita fuentes desde donde una página puede cargar o ejecutar recursos.
Content-Security-Policy: default-src 'self'; script-src 'self'CSP complementa, no reemplaza, escaping, sanitización y diseño seguro.
Servidor conceptual:
const allowedOrigins = new Set([
"https://app.example.com",
"https://admin.example.com",
]);
function applyCors(request, response) {
const origin = request.headers.origin;
if (allowedOrigins.has(origin)) {
response.setHeader(
"Access-Control-Allow-Origin",
origin,
);
response.setHeader("Vary", "Origin");
}
}No reflejes cualquier origen recibido sin validarlo.
* con credenciales.¿Por qué una API con Access-Control-Allow-Origin: * sigue necesitando autenticación?
Porque el header solo permite que páginas de otros orígenes lean la respuesta. No determina quién puede acceder al recurso ni qué acciones tiene permitidas.
Web Workers y comunicación entre contextos explica cómo ejecutar JavaScript en otro agente sin acceso directo al DOM.