Esto es el diagnóstico de una petición, no un volcado de cabeceras. Describes la llamada que hace tu código - el punto final, el origen en el que se ejecuta, el método, las cabeceras que pone, si envía credenciales - y la herramienta dice si un navegador te dejaría leer la respuesta y qué comprobación concreta lo decidió.
Qué ocurre de verdad durante un análisis
- Preparar la petición exactamente como se ha descrito.
- Clasificarla como simple o con comprobación previa, según las reglas del estándar Fetch que aplica un navegador.
- Probar la comprobación previa con una petición OPTIONS real con Origin, Access-Control-Request-Method y, si hace falta, Access-Control-Request-Headers.
- Enviar la petición real, porque la comprobación previa por sí sola nunca muestra las cabeceras CORS de la respuesta real.
- Sondear la lista de orígenes permitidos con una petición extra desde un origen que el servidor nunca ha visto.
- Construir el informe: veredicto, recorrido de la petición, cabeceras, hallazgos e intercambio técnico.
El sondeo de la lista de permitidos
Un servidor que responde a cualquier origen con ese mismo origen parece idéntico a una lista de permitidos bien configurada si solo pruebas el tuyo. Una petición desde un origen que el servidor nunca ha visto separa los dos casos, y eso importa porque un servidor que devuelve el origen como eco, junto con credenciales, es exactamente la configuración que hace que una respuesta sea legible por cualquier sitio que visite ese usuario.
Las credenciales cambian las reglas
| Cabecera | Con credenciales |
|---|
| Access-Control-Allow-OriginSin comodín | Debe nombrar el origen. Un asterisco se rechaza sin más, incluso junto a Access-Control-Allow-Credentials: true. |
| Allow-Methods, Allow-Headers, Expose-HeadersLiteral | Un asterisco deja de ser comodín y se lee como un nombre literal de cabecera o de método. |
| Access-Control-Allow-CredentialsObligatoria | Su único valor aceptado es la cadena exacta true, en minúsculas. |
Hallazgos, no adjetivos
Cada hallazgo lleva una gravedad, una categoría, la fase de la que viene, la evidencia en la que se apoya, las cabeceras a las que afecta y una recomendación. Las comprobaciones superadas también se listan, así que un resultado limpio se ve en lugar de quedar simplemente vacío. Dos reglas que siguen las recomendaciones, porque el consejo obvio suele ser el equivocado: aquí nada te dice que abras un método, una cabecera o un origen solo para que desaparezca un recuadro rojo - un DELETE bloqueado puede ser un punto final correctamente cerrado - y aquí nada sugiere nunca devolver como eco un origen arbitrario. La respuesta es una lista de permitidos, siempre.
Lo que no pretende
CORS decide qué orígenes pueden leer una respuesta dentro de un navegador. No es autenticación, no concede permisos y no detiene la falsificación de peticiones entre sitios, porque un ataque CSRF nunca necesita leer la respuesta. Cualquier cliente que no sea un navegador lo ignora por completo. Esta herramienta lo dice explícitamente, en lugar de dejar que un veredicto verde insinúe que tu punto final está protegido.