Find out whether a browser would let your code read an API response, and exactly which check blocks it. Real preflight and request diagnostics, not a header dump.
Un origen por línea, hasta diez. Útil para comprobar que local, staging y producción están todos en la lista de permitidos. Los resultados aparecen como una tabla en la pestaña Cabeceras.
Estas peticiones se envían desde los servidores de POLPROG al endpoint que indiques, porque un navegador no puede ejecutar este diagnóstico sobre sí mismo: CORS es justo lo que lo bloquearía. No se reenvía ninguna cookie tuya, nunca se envía ningún cuerpo de petición, los cuerpos de las respuestas se descartan y no se almacena nada una vez que el informe llega a ti.
Una regla del navegador, no del servidor. Cuando el JavaScript de un origen pide un recurso de otro, el navegador envía la petición pero se niega a entregar la respuesta a tu código salvo que el servidor diga, en sus cabeceras de respuesta, que el origen solicitante puede leerla. Cross-Origin Resource Sharing es el conjunto de cabeceras que sirve para decirlo.
Si una petición funciona en curl, Postman, Insomnia o desde tu propio backend, eso no dice nada sobre si el JavaScript del navegador puede leerla. Esos clientes no aplican ninguna regla de CORS. El servidor suele comportarse igual en ambos casos; la diferencia está por completo en lo que el cliente hace con la respuesta.
Para cualquier petición que no sea de las más simples, el navegador envía primero una petición OPTIONS para preguntar si la real está permitida. Lleva Origin, Access-Control-Request-Method y, si hace falta, Access-Control-Request-Headers. Si la respuesta no permite la petición, la real no se envía nunca, así que el endpoint no la ve y los registros de tu servidor no muestran nada.
Una petición es simple solo cuando su método es GET, HEAD o POST y todas las cabeceras que establece están en la lista segura de CORS: Accept, Accept-Language, Content-Language, Content-Type y Range. El valor también importa. Content-Type solo sigue en la lista segura para application/x-www-form-urlencoded, multipart/form-data y text/plain.
No está en la lista de los tres tipos de contenido de la lista segura. Esa es toda la razón. Un POST con cuerpo JSON es una petición con preflight, y por eso añadir una API JSON a una página existente produce de repente una petición OPTIONS que nadie escribió, y errores desde una ruta que solo gestiona POST.
O un único origen o *. Nunca una lista, nunca un valor con ruta, nunca un comodín dentro de un nombre de host. La comparación con el origen solicitante es exacta, así que una barra final, un puerto por defecto escrito de forma explícita o http donde la petición usó https fallarán mientras a una persona le parecen idénticos.
Necesaria cuando la petición envía cookies o autenticación HTTP. Su único valor aceptado es la cadena exacta true en minúsculas. Una petición con credenciales tampoco se puede satisfacer con Access-Control-Allow-Origin: *, y para esa misma petición un asterisco en Allow-Methods, Allow-Headers o Expose-Headers deja de ser un comodín y pasa a ser un nombre literal.
Si el servidor elige el valor de Allow-Origin a partir de la petición entrante, la respuesta depende de la cabecera Origin, y hay que avisar a cualquier caché compartida. Sin Vary: Origin, un CDN o un proxy inverso puede almacenar una respuesta que nombra a un origen y servirla a otro, así que las peticiones fallan por motivos que nunca aparecen en la aplicación.
Una respuesta de origen cruzado solo expone siete cabeceras al script: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified y Pragma. Cualquier otra, incluidas tus propias cabeceras X- y Location, se lee como null salvo que se nombre en Access-Control-Expose-Headers. Esa cabecera trata sobre la respuesta y no tiene relación con Allow-Headers, que trata sobre la petición.
Decide qué orígenes pueden leer una respuesta en un navegador. No decide quién puede llamar a un endpoint, no concede permisos y no detiene la falsificación de peticiones entre sitios: un ataque CSRF no necesita leer la respuesta, así que una política de CORS estricta lo deja intacto. Mantén la autenticación, la autorización y los tokens CSRF exactamente como estaban.
Cada veredicto de aquí procede de un intercambio real con el endpoint que indicaste, evaluado según las reglas del Fetch standard que aplica un navegador. Describe el endpoint tal como respondió a la infraestructura de POLPROG en ese momento: un servidor que varía su respuesta según la red, la región o la autenticación puede responder de otra forma a tu navegador. Los tiempos se miden desde nuestra infraestructura y no son una medición del navegador. La prueba de la petición real está desactivada por defecto para los métodos que pueden modificar datos, y nunca se envía ningún cuerpo de petición.
Porque CORS lo aplican los navegadores y nada más. Postman, curl, Insomnia y tu propio backend no aplican ninguna regla de CORS, así que reciben la respuesta lleve las cabeceras que lleve. El servidor suele comportarse igual en ambos casos. La diferencia está por completo en lo que el cliente hace con la respuesta, y un navegador se niega a entregársela a tu JavaScript salvo que la respuesta diga que ese origen puede leerla.
Una petición OPTIONS que el navegador envía antes de la real, para preguntar si la real está permitida. Lleva Origin, Access-Control-Request-Method y, cuando hace falta, Access-Control-Request-Headers. Si la respuesta no permite la petición, la real no se envía nunca, así que tu endpoint no la ve y los registros de tu servidor no muestran nada. Solo las peticiones que no son simples llevan preflight.
Content-Type solo está en la lista segura de CORS para application/x-www-form-urlencoded, multipart/form-data y text/plain. Esos tres y ninguno más. Un cuerpo JSON deja la petición fuera de la lista segura, así que el navegador la anuncia por adelantado. Por eso añadir una API JSON a una página existente produce de repente una petición OPTIONS que nadie escribió.
Porque una respuesta ligada a un usuario con sesión iniciada no debe poder leerla cualquier sitio que ese usuario visite. Cuando una petición envía cookies o autenticación HTTP, el servidor tiene que nombrar el origen en el que confía, y un navegador rechaza el comodín sin más, incluso junto a Access-Control-Allow-Credentials: true. Lo mismo vale para un asterisco en Allow-Methods, Allow-Headers y Expose-Headers: en una petición con credenciales cada uno se lee como un nombre de cabecera literal en lugar de como un comodín.
No. 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 no necesita leer la respuesta. Cualquier cliente que no sea un navegador lo ignora por completo. Mantén tu autenticación, tus comprobaciones de autorización y tus tokens CSRF exactamente como están.
Desde los servidores de POLPROG al endpoint que indiques, porque un navegador no puede ejecutar este diagnóstico sobre sí mismo: CORS es justo lo que lo bloquearía. Solo se envían las cabeceras necesarias para el análisis, no se reenvía ninguna cookie tuya, nunca se envía ningún cuerpo de petición y los cuerpos de las respuestas se descartan. No se almacena nada una vez que el informe llega a ti, y los valores de las cabeceras sensibles como Authorization nunca se muestran ni se exportan.
Una empresa suele pedir “un escáner de seguridad”, pero el problema real tiene varias capas:
Los encabezados de seguridad HTTP permiten que el servidor defina reglas para la carga de scripts, el uso de frames, las funciones del dispositivo, la información de referencia, la interpretación de tipos MIME y el acceso mediante HTTPS. Una configuración adecuada reduce el impacto de varias clases de ataques, entre ellas XSS, clickjacking, confusión MIME, XS-Leaks e incrustación cross-origin no autorizada.
Una buena auditoría web no es una única puntuación de Lighthouse ni una lista de decenas de avisos automáticos. Debe responder a cuatro preguntas: ¿puede un buscador descubrir y comprender correctamente el sitio?, ¿puede el usuario completar su tarea con facilidad?, ¿la web es suficientemente rápida? y ¿expone al propietario o a los visitantes a riesgos innecesarios?
Creamos software y soluciones a medida adaptadas a tus necesidades.