الشبكة/HTTP
CORS Checker / Explainer
شرح خطوة بخطوة ما إذا كان المتصفح سيسمح بطلب عبر النطاقات — تصنيف simple/preflight، التحقق من ترويسات Access-Control-* في الاستجابة، ملخص.
واحدة في كل سطر، "الاسم" أو "الاسم: القيمة" — القيمة لا تؤثر على التصنيف.
خذها من تبويب Network في DevTools (ترويسات الاستجابة نفسها أو preflight OPTIONS) أو من curl -I.
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.
مقالة عن هذه الأداة: CORS: لماذا يحظر المتصفح طلبات "عادية" إلى نطاق آخر
الأسئلة الشائعة
لماذا يفشل الطلب بخطأ CORS رغم أن الخادم استجاب بنجاح؟
يفرض المتصفح CORS وليس الخادم — إذا كانت الاستجابة تفتقر إلى ترويسة Access-Control-Allow-Origin مطابقة للمصدر الطالب، يمنع المتصفح JavaScript من قراءة الاستجابة، رغم اكتمال الطلب نفسه.
ما الفرق بين الطلب البسيط والطلب ذي الفحص المسبق (preflight)؟
تمر الطلبات البسيطة (GET/POST أساسية بترويسات قياسية) مباشرة، بينما تُطلق الطلبات ذات الترويسات المخصصة أو الطرق الأخرى أو أنواع محتوى معينة طلب OPTIONS مسبقًا للتحقق من الإذن قبل إرسال الطلب الفعلي.
هل يرسل فحص ترويسات CORS هنا بياناتي إلى خادم؟
تفحص الأداة الترويسات التي تقدمها أو تجلبها مباشرة من متصفحك — لا يخزّن أي خادم وسيط بيانات طلبك.
هل يحمي CORS واجهة API من الطلبات الخبيثة؟
لا. يقيّد CORS فقط ما يمكن لـJavaScript في المتصفح قراءته — مهاجم يستخدم curl أو Postman أو سكربتًا خلفيًا يتجاوزه تمامًا، لذا يجب تطبيق المصادقة والتفويض الحقيقيَّين على الخادم.
لماذا لا يعمل Access-Control-Allow-Origin: * مع credentials: include؟
تمنع المواصفة هذا الجمع عمدًا لأسباب أمنية: السماح بـ credentials (cookies، ترويسات التفويض) مع حرف بدل يقبل أي origin سيكون ثغرة أمنية خطيرة، لذا يجب أن يعيد الخادم origin محددًا عند استخدام credentials.