Ağ/HTTP
CORS Checker / Explainer
Tarayıcının çapraz kaynaklı (cross-origin) bir isteğe izin verip vermeyeceğini adım adım açıklar — simple/preflight sınıflandırması, yanıtın Access-Control-* başlıklarının kontrolü, özet.
Her satırda bir tane, "Ad" veya "Ad: değer" — değer sınıflandırmayı etkilemez.
DevTools'daki Network sekmesinden (yanıtın kendisinin veya preflight OPTIONS'ın başlıkları) ya da curl -I ile alın.
CORS (Cross-Origin Resource Sharing) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.
How to use it
- Provide the method, the request's origin, and the server's response headers (Access-Control-Allow-Origin, etc.) and the tool determines whether the browser will let the request through.
- The "simple" vs. "preflight" classification shows whether the browser will first send an OPTIONS preflight request before the actual one.
- The summary gives the exact reason for a failure when a request would be blocked — faster than parsing the browser console's error message.
Common uses
- Debugging the classic "has been blocked by CORS policy" error with a step-by-step explanation of what's missing, instead of guessing.
- Checking a backend's CORS configuration before the frontend and API end up on separate domains in production.
- Understanding why a request with credentials: include is rejected even though Access-Control-Allow-Origin looks correct.
Things to keep in mind
CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.
Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.
Sıkça sorulan sorular
Sunucu başarıyla yanıt verdiği halde bir istek neden CORS hatasıyla başarısız olur?
CORS, sunucu tarafından değil tarayıcı tarafından uygulanır — yanıtta istek yapan origin ile eşleşen bir Access-Control-Allow-Origin başlığı yoksa, isteğin kendisi tamamlanmış olsa bile tarayıcı JavaScript'in yanıtı okumasını engeller.
Basit bir istek ile preflight yapılmış bir istek arasındaki fark nedir?
Basit istekler (standart başlıklarla temel GET/POST) doğrudan geçer, özel başlıklara, farklı yöntemlere veya belirli içerik türlerine sahip istekler ise gerçek istek gönderilmeden önce izni kontrol etmek için önce bir preflight OPTIONS isteği tetikler.
Buradaki CORS başlıklarını kontrol etmek verilerimi bir sunucuya gönderiyor mu?
Araç, sağladığınız başlıkları inceler veya tarayıcınızdan doğrudan alır — hiçbir aracı sunucu istek verilerinizi saklamaz.
CORS bir API'yi kötü amaçlı isteklerden korur mu?
Hayır. CORS yalnızca tarayıcıdaki JavaScript'in ne okuyabileceğini kısıtlar — curl, Postman veya bir backend betiği kullanan bir saldırgan bunu tamamen atlar, bu yüzden gerçek kimlik doğrulama ve yetkilendirme sunucuda uygulanmalıdır.
Access-Control-Allow-Origin: * neden credentials: include ile birlikte çalışmaz?
Spesifikasyon, güvenlik nedeniyle bu kombinasyonu kasıtlı olarak yasaklar: herhangi bir origin'i kabul eden bir joker karakterle birlikte credentials'a (cookie, yetkilendirme başlıkları) izin vermek ciddi bir güvenlik açığı olurdu, bu yüzden credentials kullanılırken sunucunun tam olarak bir origin döndürmesi gerekir.