La SPA de Tienda Aroma vive en https://tiendaaroma.example. La API vive en https://api.tiendaaroma.example. La primera vez que alguien escribe un fetch desde la SPA a la API, la consola del navegador muestra el mensaje más famoso del desarrollo web:

Y entonces ocurre lo peor: alguien busca en Internet, encuentra app.use(cors()) sin argumentos, lo pega, funciona, y acaba de abrir su API a cualquier página web del mundo. Esta lección existe para que eso no pase. Vamos a entender por qué el navegador bloquea, qué protege exactamente, por qué curl y Aroma Móvil no ven ninguno de estos problemas, y cómo se configura una política que deja pasar a la SPA y al panel sin abrir la puerta a nadie más. Al terminar, src/config/cors.js existirá y el middleware cors ocupará la posición 4 de la cadena de src/app.js —la posición importa, y veremos por qué.

Advertencia. CORS es un mecanismo del navegador y no es un control de acceso del servidor. Una configuración de CORS bien hecha no sustituye a la autenticación ni a la autorización. Cualquier despliegue real debe revisarlo un profesional de seguridad. Todos los dominios y datos de esta lección son ficticios.

1. La política del mismo origen
2. Qué es exactamente un origen
3. Qué protege realmente la política del mismo origen
4. Por qué curl y Aroma Móvil no se ven afectados
5. Peticiones simples y peticiones con preflight
6. El intercambio OPTIONS completo
7. Todas las cabeceras de CORS
8. Access-Control-Expose-Headers: la que siempre falta
9. La configuración real de Tienda Aroma
10. Por qué * y Allow-Credentials son incompatibles
11. La posición en la cadena de src/app.js
12. Errores típicos y cómo leerlos en la consola
13. Cookies entre orígenes: SameSite, Secure, HttpOnly
14. CSRF: qué es y por qué Bearer es inmune
15. Otras políticas del navegador
16. CORS no autoriza nada
17. Probar CORS con curl y con las DevTools

La política del mismo origen (Same-Origin Policy, SOP) es la regla de seguridad fundamental de los navegadores: el código JavaScript de una página solo puede leer respuestas de su propio origen.

Es lo que impide esto:

Sin la SOP, cualquier página que visitaras podría, en segundo plano, leer tu correo, tu banco y tu intranet aprovechando las sesiones que ya tienes abiertas. La web sería inutilizable.

Y ahora la parte incómoda: la SOP también bloquea tu propia SPA llamando a tu propia API, porque el navegador no tiene forma de saber que tiendaaroma.example y api.tiendaaroma.example son la misma organización.

CORS (Cross-Origin Resource Sharing) es el mecanismo estandarizado por el que el servidor dice al navegador: «este origen concreto sí puede leer mis respuestas». Es decir:

CORS no es una defensa. Es una relajación controlada de una defensa que ya existe.

Interiorizar esa frase evita el 90 % de los errores conceptuales sobre CORS.

Un origen es la tripleta esquema + host + puerto. Los tres tienen que coincidir, exactamente, sin excepciones.

Tomando https://tiendaaroma.example como referencia:

Dos consecuencias prácticas:

Un subdominio es otro origen. Esta es la fuente número uno de sorpresa: mucha gente asume que api.tiendaaroma.example es "lo mismo" que tiendaaroma.example. Para el navegador no lo es, y por eso Tienda Aroma necesita CORS.

La última fila importa para la seguridad. Al validar orígenes, origen.startsWith('https://tiendaaroma.example') acepta https://tiendaaroma.example.evil.example, un dominio que cualquiera puede registrar. La comparación tiene que ser de igualdad exacta contra una lista blanca.

Aquí hay una sutileza que casi todo el mundo entiende mal al principio, y que cambia por completo cómo se razona sobre CORS.

La petición se envía. Cuando tu página hace fetch a otro origen sin preflight, el navegador envía la petición al servidor y el servidor la procesa. Lo que la SOP bloquea es que el JavaScript de la página lea la respuesta.

Consecuencias que hay que tener muy claras:

• Si el endpoint tiene efectos secundarios, ocurren igualmente. Un GET que borrase algo lo borraría, aunque el atacante no viera la respuesta. Es un argumento más para la safety del GET de 02-03.
• CORS no protege tu servidor de nada. Protege los datos del usuario impidiendo que otra página los lea con las credenciales de ese usuario.
• El atacante no ve el error. El JavaScript recibe un TypeError: Failed to fetch genérico, sin código de estado ni cuerpo. Es deliberado: si viera el 401 o el 404, ya tendría información.

Las peticiones con preflight (apartado 5) sí se detienen antes de enviarse, y ahí sí hay una protección real del servidor: por eso Content-Type: application/json y Authorization disparan preflight.

curl no aplica CORS. Ni Postman, ni un script de Node, ni el backend de CataBox, ni la app Aroma Móvil (que hace peticiones nativas, no desde un contexto de navegador). CORS lo implementa el navegador, y solo el navegador, porque es el único que ejecuta código de terceros con las credenciales del usuario.

De ahí se sigue la conclusión más importante de la lección, que hay que repetir hasta que resulte obvia:

Una política de CORS restrictiva no impide a nadie llamar a tu API. Solo impide que una página web de otro origen lea la respuesta desde el navegador de un usuario. La protección real de tus datos es, siempre, la autenticación y la autorización del servidor.

El navegador distingue dos categorías, y la diferencia es visible en el rendimiento y en los errores.

Se envían directamente, sin consulta previa. Deben cumplir todas estas condiciones:

• Método GET, HEAD o POST.
• Cabeceras limitadas a las «seguras de lista»: Accept, Accept-Language, Content-Language, Content-Type (con restricciones) y algunas más.
• Content-Type solo puede ser application/x-www-form-urlencoded, multipart/form-data o text/plain.
• Sin manejadores de eventos de subida en el XMLHttpRequest.

La razón histórica de esta lista: son exactamente las peticiones que un formulario HTML podía hacer antes de que existiera CORS. Como ya eran posibles, exigir permiso previo no habría añadido seguridad y sí habría roto la web.

Cualquier cosa fuera de esa lista dispara una petición previa OPTIONS. En Tienda Aroma, eso significa casi todas:

Como nuestra API usa Authorization: Bearer y application/json en todas partes, prácticamente todo el tráfico de la SPA lleva preflight. Por eso Access-Control-Max-Age (apartado 7) tiene un impacto real en el rendimiento: sin caché de preflight, cada petición se convierte en dos.

Veamos, en crudo, lo que ocurre cuando la SPA crea un pedido.

Paso 1: el preflight. Lo genera el navegador solo; tu código nunca lo escribe:

Fíjate en tres cosas: no lleva cuerpo, no lleva el Authorization real (solo anuncia que lo va a mandar) y las cabeceras anunciadas van en minúsculas y ordenadas.

Paso 2: la respuesta al preflight.

Paso 3: la petición real. Solo si el paso 2 lo permitió:

Paso 4: la respuesta real. Y aquí está el punto que se olvida siempre: la respuesta real también necesita Access-Control-Allow-Origin. Que el preflight haya ido bien no basta.

Sin Expose-Headers, la SPA recibiría el 201 y el cuerpo, pero respuesta.headers.get('Location') devolvería null.

Que Origin no sea falsificable desde JavaScript es lo que hace que el mecanismo funcione: el navegador la escribe y no deja al script tocarla. Ahora bien, un cliente que no sea un navegador puede escribir lo que quiera (curl -H "Origin: ..."), y por eso Origin no sirve como control de acceso.

Dos detalles que causan bugs:

Allow-Origin admite un único valor. No existe Access-Control-Allow-Origin: https://a.example, https://b.example. Para varios orígenes, el servidor refleja el origen recibido si está en su lista blanca. Eso es lo que hace el paquete cors con una función origin.

Max-Age tiene topes del navegador. Aunque pidas 86.400 segundos, los navegadores imponen su propio máximo (del orden de dos horas en Chromium, menos en otros). Un valor de 600 es un buen equilibrio: reduce mucho los preflights y no deja un cambio de política congelado demasiado tiempo.

Si el servidor refleja el origen, la respuesta depende de la cabecera Origin. Sin Vary: Origin, cualquier caché intermedia —una CDN, un proxy corporativo, la caché del navegador— puede guardar la respuesta para https://tiendaaroma.example y servírsela a una petición de https://panel.tiendaaroma.example, que entonces recibirá un Allow-Origin equivocado y fallará de forma intermitente e inexplicable.

Es la misma mecánica de Vary que vimos en 02-05 con Accept-Language, y la retomaremos en 04-06 al hablar de caché. Los tres casos son el mismo principio: si la respuesta depende de una cabecera de la petición, dilo en Vary.

Por defecto, el JavaScript de otro origen solo puede leer siete cabeceras de respuesta, las llamadas «seguras de lista»:

Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified, Pragma.

Todas las demás son invisibles, aunque estén ahí. Y eso arrasa con buena parte de lo que hemos construido en este curso:

Este es el eslabón que unía las tres lecciones anteriores. Tienda Aroma expone exactamente esto:

Y un criterio de diseño: se expone lo necesario, no todo. Existe el comodín * para Expose-Headers, pero no funciona cuando hay credenciales y, sobre todo, exponer cabeceras de infraestructura filtra información innecesaria.

Y la validación en el arranque, coherente con 03-01: si en producción no hay orígenes configurados, el proceso no debe arrancar, porque la alternativa silenciosa es peor.

Access-Control-Allow-Origin: * significa «cualquier página web del mundo puede leer esta respuesta». Hay un caso en el que es perfectamente razonable:

La prohibición es explícita en la especificación: si Access-Control-Allow-Credentials: true, entonces Access-Control-Allow-Origin no puede ser *. Tiene que ser un origen concreto.

El motivo es claro cuando se piensa en el ataque que evita: si se permitiera, cualquier página web podría hacer peticiones con las cookies de sesión del usuario a cualquier API y leer el resultado. Sería la eliminación completa de la política del mismo origen. El comodín solo puede aplicarse a datos que no dependen de quién pregunta, y en cuanto hay credenciales, dependen.

Un matiz que confunde: credentials: 'include' en el fetch afecta a cookies y cabeceras de autenticación HTTP gestionadas por el navegador, no a un Authorization: Bearer que tú pones a mano. Aun así, con Bearer se sigue necesitando una lista blanca, porque el token identifica al usuario y la respuesta depende de él.

Decisión de Tienda Aroma: lista blanca en toda la API. Se podría hacer una excepción con * en GET /v1/cafes, que es público y cacheable, pero mantener una sola política es más simple, menos frágil y coherente con el principio de consistencia de 04-01.

Por qué la posición 4 y no otra. Es la decisión más importante de esta lección:

• Antes del rate limiting (6): si no, un 429 sale sin cabeceras de CORS y el navegador lo convierte en un error de red opaco. El desarrollador de la SPA ve «Failed to fetch» y no tiene ni idea de que ha superado un límite.
• Antes del parser de JSON (7): el preflight OPTIONS no lleva cuerpo, pero un POST con JSON mal formado produciría un 400 sin cabeceras CORS, y otra vez la SPA vería un error inútil.
• Antes de las rutas (9) y, por tanto, antes de toda autenticación: esta es la clave del error clásico del apartado 12. El preflight OPTIONS no lleva Authorization —el navegador no lo envía nunca—, así que si el middleware de autenticación se ejecutara antes, respondería 401 al preflight y la petición real nunca se enviaría.
• Después de helmet (3): para que la respuesta al preflight lleve también las cabeceras de seguridad y para que, si helmet y CORS entran en conflicto (el caso de Cross-Origin-Resource-Policy que vimos en 04-02), CORS tenga la última palabra sobre sus propias cabeceras.
• Después de la traza (2): para poder correlacionar un preflight fallido en los logs.

Y una consecuencia de diseño que conviene notar: el paquete cors responde al OPTIONS y termina la cadena (preflightContinue: false). El preflight no llega a las rutas, así que el router.all(...) con metodoNoPermitido(...) de cada ruta no interfiere con él.

Traducción: el OPTIONS devolvió 401. Y devolvió 401 porque el middleware de autenticación se ejecutó antes que el de CORS, y el preflight no lleva Authorization: el navegador nunca lo incluye, por diseño, porque el preflight es una consulta sobre la política, no una petición de datos.

La confusión aquí es doble, y por eso el error dura tardes enteras: el mensaje habla de CORS, pero la causa es el orden de los middlewares; y la petición que falla (OPTIONS) no es la que escribiste (POST). La regla de diagnóstico: cuando falle CORS, abre la pestaña de red del navegador y busca la petición OPTIONS. Si no está, el problema es otro. Si está y no devuelve 2xx, ahí está el fallo, y su código de estado te dice exactamente qué middleware lo interceptó.

Si Tienda Aroma usara cookies de sesión en lugar de Authorization: Bearer, la configuración necesaria sería:

El problema salta a la vista: SameSite=None es exactamente lo que hay que poner para que funcione entre tiendaaroma.example y api.tiendaaroma.example, y es exactamente lo que reabre la puerta al CSRF. A cambio hay que añadir tokens anti-CSRF, y encima SameSite=None requiere Secure y está sujeto a las restricciones de cookies de terceros que los navegadores llevan años endureciendo.

Por eso Tienda Aroma usa Authorization: Bearer:

Ninguna opción es perfecta: Bearer elimina el CSRF pero traslada el riesgo al almacenamiento del token en el cliente (04-03). Para una API consumida por SPA, app móvil y terceros, Bearer es la opción coherente, y por eso credentials: false en nuestra configuración de CORS.

CSRF (Cross-Site Request Forgery) es un ataque que aprovecha que el navegador adjunta las cookies automáticamente. La víctima, con sesión abierta en Tienda Aroma, visita una página maliciosa:

El navegador envía la petición con las cookies de sesión de la víctima. El atacante no puede leer la respuesta (la SOP se lo impide), pero no le hace falta: el pedido ya se ha creado. CSRF es un ataque de escritura a ciegas.

Por qué Tienda Aroma es inmune:

1. Usa Authorization: Bearer, y el navegador no adjunta esa cabecera automáticamente. Un formulario de otro sitio no puede añadirla.
2. Exige Content-Type: application/json, que un formulario HTML no puede producir (el truco del enctype="text/plain" del ejemplo es precisamente para intentar esquivarlo, y nuestro express.json({type: [...]}) rechaza ese tipo).
3. Toda escritura dispara preflight, y el preflight fallaría porque sitio-malicioso.example no está en la lista blanca.

Las tres son consecuencia de decisiones que ya estaban tomadas. Si algún día se migrara a cookies, harían falta defensas explícitas:

Y la advertencia final del apartado: CSRF y CORS son cosas distintas y a menudo se confunden. CORS controla quién puede leer respuestas; CSRF explota que las peticiones se envían con credenciales. Configurar CORS estrictamente no elimina el CSRF si usas cookies, porque las peticiones simples se envían igualmente.

CORS no es la única política que gobierna la relación entre la SPA y la API.

Referrer-Policy, que ya activamos con helmet en 04-02 con el valor no-referrer. Controla cuánta información de la URL de origen se envía al navegar o al cargar recursos. Importa porque nuestras URIs contienen identificadores (/v1/pedidos/ped_5001) y no queremos que aparezcan en los logs de terceros.

Permissions-Policy (antes Feature-Policy) declara qué capacidades del navegador puede usar un documento: cámara, micrófono, geolocalización. Es una cabecera para documentos HTML, así que la pone la SPA, no la API:

Content-Security-Policy en la SPA, y en concreto la directiva connect-src, que es el complemento simétrico de CORS: mientras CORS dice qué orígenes pueden leernos, connect-src dice a qué orígenes puede llamar la SPA.

Su valor defensivo es concreto: si un atacante logra inyectar JavaScript en la SPA (un XSS), connect-src le impide exfiltrar los datos a su propio servidor, porque el navegador bloqueará el fetch a un dominio no declarado. Es la razón de que CSP sea una defensa en profundidad valiosa incluso cuando ya sanitizas las entradas.

La API, que no sirve HTML, mantiene su default-src 'none' de 04-02: nada que cargar, nada que ejecutar.

Merece un apartado propio porque es el malentendido con peores consecuencias.

CORS es una instrucción para el navegador. No es un control de acceso.

Una API con Access-Control-Allow-Origin: https://tiendaaroma.example y sin autenticación es una API completamente abierta: cualquiera con curl accede a todo. Y una API con la política de CORS más restrictiva del mundo sigue siendo vulnerable a BOLA si no comprueba la propiedad de los recursos (04-02).

La regla de oro:

Configura CORS pensando en proteger a tus usuarios en su navegador. Configura autenticación y autorización pensando en proteger tus datos de todo lo demás. Nunca sustituyas la segunda por la primera.

curl no aplica CORS, pero sirve perfectamente para inspeccionar las cabeceras que emite el servidor, que es lo que queremos verificar.

1. Pestaña Red, filtro «Fetch/XHR», y activa «Preserve log» para que no se pierdan al navegar.
2. Busca la petición OPTIONS. Si falla, ahí está el problema; su código de estado señala el culpable.
3. En «Headers», compara Access-Control-Request-Headers (lo que pide el navegador) con Access-Control-Allow-Headers (lo que concede el servidor). La diferencia es tu error.
4. Comprueba en la respuesta real que están Access-Control-Allow-Origin y Access-Control-Expose-Headers.
5. Si la respuesta llega pero una cabecera es null en el código, es Expose-Headers. Las DevTools sí muestran todas las cabeceras aunque JavaScript no pueda leerlas: esa discrepancia entre «la veo en las DevTools pero headers.get() da null» es la firma inconfundible del problema.

La tercera prueba es la más valiosa de las cuatro: fija el orden de los middlewares. Si alguien mueve cors después de la autenticación, esta prueba falla con un 401 y el problema se detecta en la integración continua en vez de en la consola de un desarrollador de la SPA.

Usar app.use(cors()) sin opciones. Equivale a Access-Control-Allow-Origin: * en toda la API. Funciona, y por eso es tan peligroso: el problema no se manifiesta nunca.

Validar el origen con startsWith o una expresión regular laxa. https://tiendaaroma.example.evil.example pasaría el filtro. Igualdad exacta contra un Set.

Olvidar Vary: Origin. Produce fallos intermitentes que dependen de qué haya cacheado la CDN, y son de los bugs más difíciles de reproducir.

Poner cors después de la autenticación. El preflight recibe 401 y nada funciona, con un mensaje que apunta en otra dirección.

Olvidar exposedHeaders. La SPA no puede leer Location, Link, ETag ni Retry-After, y buena parte del trabajo de los módulos 2, 3 y 4 queda invisible para ella.

Intentar arreglar CORS desde el cliente. No se puede: la decisión es del servidor. Los proxies y extensiones que «desactivan CORS» solo sirven en tu máquina y ocultan el problema real.

Creer que mode: 'no-cors' en el fetch soluciona algo. Devuelve una respuesta opaca: no puedes leer ni el cuerpo ni el estado. Casi nunca es lo que quieres.

Añadir un origen a la lista blanca «temporalmente» para depurar. Los * temporales se quedan para siempre. Usa un entorno de desarrollo con su propia configuración.

Consejo: la respuesta al preflight también necesita las cabeceras de seguridad. Por eso helmet va antes que CORS.

Consejo: cuando falle CORS, mira la pestaña de red antes que la consola. El mensaje de la consola es un resumen; la petición OPTIONS es la evidencia.

Consejo: documenta la lista de orígenes permitidos. Cuando la SPA cambie de dominio, alguien tendrá que actualizarla, y si no está escrito nadie sabrá dónde.

Para cada petición desde https://tiendaaroma.example, di si dispara preflight y por qué:

1. fetch('https://api.tiendaaroma.example/v1/cafes')
2. fetch('https://api.tiendaaroma.example/v1/cafes', { headers: { Authorization: 'Bearer x' } })
3. fetch('https://api.tiendaaroma.example/v1/pedidos', { method: 'POST', body: 'hola', headers: { 'Content-Type': 'text/plain' } })
4. fetch('https://api.tiendaaroma.example/v1/pedidos', { method: 'POST', body: '{}', headers: { 'Content-Type': 'application/json' } })
5. fetch('https://tiendaaroma.example/api/cafes')
6. fetch('https://api.tiendaaroma.example/v1/cafes/caf_001', { method: 'DELETE' })

Diagnostica cada situación y propón la corrección concreta:

• (a) La SPA crea un pedido correctamente (201), pero respuesta.headers.get('Location') devuelve null.
• (b) El panel interno funciona desde la máquina de un desarrollador y falla en producción con No 'Access-Control-Allow-Origin' header.
• (c) Tras poner una CDN delante, la SPA falla una de cada cinco veces con un Allow-Origin que corresponde al panel.
• (d) POST /v1/pedidos falla desde la SPA con «Response to preflight request doesn't pass access control check», pero el mismo POST con curl funciona.

Tienda Aroma va a permitir que CataBox (https://catabox.example) llame a la API desde su propia SPA en el navegador, usando OAuth con Authorization: Bearer y solo el ámbito pedidos.leer. Escribe la configuración de CORS necesaria y responde: ¿basta con añadir el origen a la lista blanca para que CataBox pueda leer los pedidos? ¿Qué más hace falta y qué no aporta CORS aquí?

Solución 1

Observación sobre el caso 3: aunque no dispare preflight, nuestra API lo rechazaría igualmente con un 400, porque express.json está configurado con type: ['application/json', 'application/merge-patch+json'] y no parsea text/plain. Ese rechazo es justamente lo que hace que el truco del formulario CSRF del apartado 14 no funcione.

Solución 2

(a) Falta Location en exposedHeaders. La respuesta llega completa y la cabecera está ahí —se ve en las DevTools—, pero el navegador no deja que JavaScript la lea porque no es una de las siete seguras de lista. Corrección: añadir Location a exposedHeaders en src/config/cors.js.

(b) La variable ORIGENES_PERMITIDOS de producción no incluye el dominio del panel. En desarrollo funcionaba porque origenesPermitidos() añade localhost cuando NODE_ENV es desarrollo. Corrección: añadir https://panel.tiendaaroma.example a la configuración del entorno de producción y redesplegar. Verificación: curl -sI -H 'Origin: https://panel.tiendaaroma.example' ....

(c) Falta Vary: Origin. La CDN cachea la respuesta —incluida su cabecera Access-Control-Allow-Origin— sin saber que depende de Origin, y la sirve indistintamente a los dos orígenes. El fallo es intermitente porque depende de qué respuesta esté cacheada. Corrección: emitir Vary: Origin (el paquete cors lo hace cuando se usa una función origin, pero hay que verificar que la CDN lo respeta y no lo elimina).

(d) El preflight no llega a responderse correctamente. curl funciona porque no hace preflight. Las dos causas probables, en orden: el middleware de autenticación se ejecuta antes que cors y responde 401 al OPTIONS; o falta Idempotency-Key en allowedHeaders, con lo que el navegador rechaza el preflight aunque devuelva 204. Diagnóstico: mirar la petición OPTIONS en la pestaña de red. Si devuelve 401, es lo primero; si devuelve 204 pero el Access-Control-Allow-Headers no incluye idempotency-key, es lo segundo.

Solución 3

No hace falta nada más en la configuración: CataBox usa Authorization: Bearer, que ya está en allowedHeaders, y credentials sigue en false porque no hay cookies.

¿Basta con eso para que CataBox lea los pedidos? No. Añadir el origen solo permite que el navegador entregue la respuesta al JavaScript de CataBox. Para que la API devuelva datos hacen falta tres cosas más, todas del lado del servidor:

1. Un token válido emitido por el servidor de autorización, con aud igual a nuestra API (04-03).
2. El ámbito pedidos.leer en ese token, comprobado por exigirAmbito.
3. La comprobación de propiedad: el token solo da acceso a los pedidos de su sub, no a los de cualquiera (04-02).

Qué no aporta CORS aquí: absolutamente ninguna autorización. Si mañana el backend de CataBox llama a la API desde su servidor, no habrá Origin ni CORS de por medio, y el acceso seguirá funcionando o fallando exactamente igual, según el token. Y una nota práctica: como la SPA de CataBox es un cliente público, debe usar Authorization Code + PKCE y no puede guardar un client_secret (04-03).

CORS deja de ser un misterio en cuanto se entiende que no es una defensa, sino una relajación controlada de una defensa que ya existe: la política del mismo origen, que impide que el JavaScript de una página lea respuestas de otro origen. Sabes qué es exactamente un origen —esquema, host y puerto, con el subdominio contando como distinto—, que la petición se envía aunque la respuesta se bloquee, y por qué curl, Aroma Móvil y el backend de CataBox no ven nada de esto. Distingues peticiones simples de las que disparan preflight, y has visto el intercambio OPTIONS completo en crudo, con la observación clave de que la respuesta real también necesita sus cabeceras de CORS. Conoces las siete cabeceras del protocolo, la importancia de Vary: Origin frente a las cachés, y sobre todo Access-Control-Expose-Headers, que era el eslabón que faltaba para que la SPA pueda leer Location, Link, ETag, Retry-After y las Aroma-RateLimit-* que llevamos tres lecciones construyendo. En el proyecto tienes src/config/cors.js con lista blanca por entorno validada al arrancar, y el middleware en la posición 4 de src/app.js: después de helmet, antes del rate limiting, del parser y de toda autenticación —que es precisamente lo que evita el clásico preflight con 401—. Y tienes claro por qué Tienda Aroma usa Authorization: Bearer en lugar de cookies, lo que la hace inmune a CSRF sin necesidad de tokens sincronizadores.

Con la API asegurada, delimitada y accesible desde los orígenes correctos, queda hacerla rápida. En 04-06, Caché HTTP y rendimiento, recuperaremos la restricción «cacheable» de 01-04 y la convertiremos en implementación: los niveles de caché desde el navegador hasta la base de datos; Cache-Control a fondo, con max-age, s-maxage, private, ese no-cache que no significa «no cachear», stale-while-revalidate e immutable; la validación condicional con ETag y Last-Modified que produce un 304 sin cuerpo; y el reencuentro que llevamos anunciando desde 03-05, cuando If-Match y el 412 cierren el círculo de la concurrencia optimista y expliquen por qué una cabecera es mejor sitio que el cuerpo para el campo version. Añadiremos src/middleware/cache.js, veremos la invalidación —el problema difícil—, la caché de servidor con Redis y su patrón cache-aside, la compresión, el N+1, el 202 para las operaciones largas, y por qué hay que medir p50, p95 y p99 antes de optimizar nada.