¿Qué es el error CORS y a quién protege realmente? (Same-Origin Policy y Preflight OPTIONS)

Todo desarrollador web se ha topado con este clásico error rojo en la consola del navegador:

Access to fetch at 'https://api.ejemplo.com/v1/transfer' from origin 'http://localhost:3000' has been blocked by CORS policy

¿Por qué la misma petición funciona en Postman o cURL pero falla en el navegador? Porque CORS (Cross-Origin Resource Sharing) no es un cortafuegos del servidor, sino una medida de seguridad del navegador que protege al usuario.

1. ¿Por qué existe la Same-Origin Policy (SOP)?

Sin la Same-Origin Policy, si tuvieras abierta la sesión de tu banco (https://banco.com) en una pestaña y abrieras una web maliciosa (https://evil.com) en otra, el JavaScript de evil.com podría hacer peticiones en segundo plano usando tus cookies y leer tus datos privados. SOP impide que un origen externo lea las respuestas de otro dominio.

2. Cómo funciona CORS de forma segura

Cuando tu frontend (https://app.empresa.com) y tu API (https://api.empresa.com) están en subdominios distintos, el servidor debe autorizar explícitamente al origen mediante una lista blanca (Whitelist):

Access-Control-Allow-Origin: https://app.empresa.com
Access-Control-Allow-Credentials: true

3. Peticiones Preflight (OPTIONS) y Access-Control-Max-Age

Al enviar Content-Type: application/json o métodos como PUT/DELETE, el navegador envía primero una petición oculta OPTIONS (Preflight) para pedir permiso. Para evitar duplicar la latencia de red en cada llamada a la API, puedes indicar al navegador que guarde en caché ese permiso:

Access-Control-Max-Age: 86400

Con esta cabecera, el navegador almacena la autorización CORS en su caché durante 24 horas y elimina las peticiones OPTIONS repetitivas.