Texto y documentos
Números y cálculo
Datos y formatos
Seguridad
Desarrollo y DevOps
Inteligencia Artificial
Finanzas
Salud y bienestar
Productividad
Juegos y entretenimiento
Multimedia y diseño
Empresa
Guía de uso
Qué es y para qué sirve

CORS (Cross-Origin Resource Sharing) es el mecanismo por el que un navegador decide si una web puede leer la respuesta de una API alojada en otro origen (otro dominio, puerto o protocolo). Sin las cabeceras CORS correctas, el navegador bloquea la lectura por seguridad. Esta herramienta simula esa comprobación del navegador: te explica, sin hacer ninguna petición real y todo en tu navegador, si tu servidor permitiría la llamada y por qué.

Qué introducir

Rellena tres cosas:

Origen (navegador) — la URL de la app que hace la petición (p. ej. https://myapp.com). Es el valor que el navegador enviaría en la cabecera Origin.
Método HTTPGET, POST, PUT, DELETE… El método decide si hace falta un preflight.
Headers de respuesta del servidor — pega las cabeceras que devuelve tu API, una por línea, con formato Nombre: valor (p. ej. Access-Control-Allow-Origin: *). El análisis se actualiza solo mientras escribes.

Petición simple vs preflight

Hay dos formas de petición cross-origin:

Petición simple — con GET, POST o HEAD y cabeceras básicas, el navegador la envía directamente y luego comprueba si la respuesta trae Access-Control-Allow-Origin.
Con preflight — con métodos como PUT, PATCH o DELETE (o cabeceras personalizadas), el navegador manda antes una petición previa de tipo OPTIONS para pedir permiso. La herramienta marca automáticamente cuándo tu método requiere preflight.

El preflight (OPTIONS) en detalle

El preflight es una petición OPTIONS que el navegador envía antes de la real para preguntar «¿me dejas hacer esto?». En esta herramienta se dispara con los métodos PUT, PATCH, DELETE y OPTIONS. Cuando aparece el aviso, tu servidor debe responder a ese OPTIONS con las cabeceras CORS adecuadas (origen, métodos y cabeceras permitidas); si no, el navegador cancela la petición real aunque tu API funcione. Añadir Access-Control-Max-Age evita repetir el preflight en cada llamada.

Access-Control-Allow-Origin

Es la cabecera imprescindible: indica qué origen puede leer la respuesta.

* — permite cualquier origen, pero no funciona con credenciales (cookies).
• Un origen concreto, p. ej. https://myapp.com — solo ese origen, y debe coincidir exactamente con tu Origen (protocolo + dominio + puerto).

Si falta esta cabecera, o el valor no coincide con * ni con tu origen, la petición se bloquea.

Access-Control-Allow-Methods

Lista los métodos HTTP que el servidor acepta desde otro origen, separados por comas (p. ej. GET, POST, PUT, DELETE). Es relevante sobre todo en el preflight. Si indicas esta cabecera pero no incluye tu método, la herramienta lo señala como problema y bloquea la petición. Si no la pones, el método no se comprueba.

Access-Control-Allow-Headers

Enumera qué cabeceras de petición puede enviar el cliente (p. ej. Content-Type, Authorization). El navegador la exige en el preflight cuando tu petición manda cabeceras no estándar. Si tu app envía Authorization y aquí no aparece, el navegador bloqueará la llamada.

Access-Control-Allow-Credentials

Con valor true permite enviar cookies y credenciales en la petición cross-origin.

Ojo, gotcha importante: las credenciales son incompatibles con Access-Control-Allow-Origin: *. Si usas credenciales, el origen debe ser específico (p. ej. https://myapp.com), nunca *. Combinar ambos hace que el navegador rechace la respuesta.

Access-Control-Max-Age y Vary

Access-Control-Max-Age indica cuántos segundos puede el navegador cachear la respuesta del preflight (p. ej. 86400 = 24 h), para no repetir el OPTIONS en cada llamada. La herramienta la incluye en los headers sugeridos cuando tu método necesita preflight. Recuerda además añadir Vary: Origin en tu servidor cuando devuelvas un origen concreto, para que las cachés no mezclen respuestas de orígenes distintos.

Cómo leer el resultado

Tras el análisis verás:

• Un banner verde (permitido) o rojo (bloqueado) con el motivo exacto: falta Access-Control-Allow-Origin, el origen no coincide o el método no está permitido.
Headers CORS encontrados — cada cabecera detectada con su valor y una explicación.
Problemas detectados — lo que impide la petición.
Funciona, pero es un riesgo de seguridad — lo que el navegador SÍ deja pasar y no deberías querer, como admitir el origen null con credenciales.
Tu navegador lo permite, pero no te fíes — lo que Chrome acepta hoy y la especificación no garantiza.
Headers sugeridos — un bloque listo para copiar a la configuración de tu servidor.

CORS ExplainerAnaliza headers CORS de tu servidor
CORS ExplainerAnaliza y explica los headers CORS de tu servidor
URL de la app que hace la petición

Márcalo si tu código usa credentials: 'include' (o withCredentials). Cambia las reglas: el origen ya no puede ser *, los comodines dejan de valer y el servidor tiene que responder Access-Control-Allow-Credentials: true.

Las de la PETICIÓN, no las de la respuesta. Son las que deciden si el navegador manda antes un OPTIONS, y las que «Access-Control-Allow-Headers» tiene que cubrir.

CORS permitido correctamente
El navegador mandará antes una petición OPTIONS (preflight), por el Content-Type application/json. Tu servidor tiene que contestar también a ESE OPTIONS, no solo a la petición real.

Headers CORS encontrados

Access-Control-Allow-Originhttps://myapp.comPermite solo el origen: https://myapp.com
Access-Control-Allow-MethodsPOSTMétodos permitidos: POST
Access-Control-Allow-HeadersContent-TypeCabeceras permitidas en la petición: Content-Type

Headers sugeridos para tu servidor

Access-Control-Allow-Origin: https://myapp.com
Vary: Origin
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400
Esto se decide sobre las cabeceras que pegues, sin salir a la red — por eso vale también para una API local o privada. Si quieres lanzar la petición de VERDAD y ver si tu servidor llegó a contestar, está el Banco de trabajo de APIs.