Límites del navegador: origen, CORS y CSRF

Tienes el banco abierto en una pestaña y una receta en otra. ¿Qué impide que la receta lea los datos del banco? La respuesta empieza por los límites de origen.

Origen: En el modelo web habitual, combinación de esquema, host y puerto utilizada como límite de seguridad del navegador.

Un origen es un límite de dirección

Un origen combina esquema, host y puerto. Dos direcciones pueden ser de distinto origen aunque parezcan parte del mismo sitio. Las reglas de cookies también usan el concepto de sitio, que no significa exactamente lo mismo.

La política del mismo origen restringe muchas interacciones entre orígenes, especialmente que un script lea datos de otro. No significa que el navegador nunca pueda enviar solicitudes entre orígenes: la navegación, los formularios y las imágenes tienen comportamientos propios.

CORS permite compartir respuestas

CORS permite que un servidor indique al navegador qué orígenes pueden leer una respuesta. Algunas solicitudes necesitan una comprobación previa; otras pueden enviarse sin ella. Un error CORS no demuestra por sí solo que la solicitud nunca llegó al servidor.

Los navegadores aplican CORS. Otros clientes no están sujetos a esa política, así que no autentica al usuario ni sustituye los permisos de una API.

Protege también los cambios

Una acción autenticada mediante cookies, como cambiar una dirección de entrega, necesita protección contra solicitudes no deseadas desde otros sitios. Según la aplicación, pueden ayudar los tokens anti-CSRF, las comprobaciones de origen y los atributos de cookies. Los métodos seguros no deberían efectuar cambios inesperados.

Separa tres preguntas: quién hace la solicitud, qué puede hacer y si esta acción procede del flujo previsto. El cifrado protege el transporte, no decide los permisos.

Revisión resuelta: identifica la etapa bloqueada

Una tienda ficticia tiene una vista previa alojada por separado. Los registros son observaciones de diseño aportadas. Describen decisiones del navegador sin pedir construir ni enviar solicitudes.

• B1: Perfil y pedidos usan HTTPS, host shop.example y puerto efectivo 443. Cambia su ruta. La vista previa usa el mismo esquema y host, pero puerto 8443.
• B2: La evaluación confirma que una solicitud de la vista previa llegó al servicio. El navegador denegó después al script leer la respuesta porque CORS no lo permitía. No se aporta registro de efectos de negocio.
• B3: Otro origen aprobado expresamente puede leer ciertas respuestas API. El servicio tiene cuentas con distintos permisos sobre pedidos.
• B4: El cambio de dirección comprueba sesión por cookie y propiedad del pedido. Considera la cookie evidencia suficiente del flujo previsto; no documenta protección separada frente a cambios no deseados desde otros sitios.

Predice¿Puede resumirse B2 como “el navegador bloqueó la operación y el servidor no hizo nada”?

No. La recepción es explícita; se bloqueó la lectura de respuesta por el script. El paquete no establece si el servicio cambió algo. Una comprobación previa rechazada puede impedir la solicitud real en otros casos, pero no es lo registrado aquí.

Separar las decisiones del servidor

B1 muestra que un host familiar no resuelve la identidad del origen. Perfil y pedidos comparten origen aunque cambie su ruta. La vista previa no, porque cambia el puerto efectivo. La comparación no establece identidad de cuenta ni permisos sobre pedidos.

En B3, una lista CORS precisa sirve para compartir deliberadamente con navegadores. No autentica a todo cliente ni expresa de quién es cada pedido. Un origen permitido puede contener varios usuarios y el servidor debe conservar la decisión entre usuario y recurso.

B4 requiere definir el flujo previsto además de autenticar y autorizar. Pueden contribuir tokens anti-CSRF adecuados, información de origen validada y políticas apropiadas de cookies, documentando sus supuestos. Ninguno demuestra toda intención humana ni sustituye la comprobación del pedido.

Nota modelo: verifica tres decisiones por separado: si hubo envío, si el script pudo leer y si el servidor autorizó el cambio concreto dentro del flujo esperado. Indica evidencia ausente en vez de usar una etiqueta genérica de bloqueo. Incluye cambios legítimos de dirección en la aceptación para evitar presentar una denegación universal como corrección útil.

EXPLORA EL CONCEPTO

¿Qué límite actúa?

Elige una afirmación y comprueba qué demuestra.

Aparece un error CORS

El script no puede leer la respuesta. La solicitud puede haber llegado al servidor.

La API comprueba los permisos del objeto

El servidor decide si la identidad puede actuar sobre ese objeto, independientemente de CORS.

Se valida un token anti-CSRF

Aporta una señal adicional sobre el flujo de la solicitud. Todavía hace falta autorización.

Modelo simplificado para aprender. No se conecta a sistemas ni usa datos reales.

Llévalo a una decisión

Cuando digas que el navegador bloqueó algo, aclara si bloqueó el envío, la lectura o una operación concreta.