- بواسطة x32x01 ||
أخيرًا فهمت يعني إيه CORS!إزاي بيشتغل؟ مين اللي بينفذه؟ وليه أصلا موجود؟
أكيد قابلت الرسالة دي قبل كده وانت بتشتغل على API أو مشروع ويب: "CORS error"
والموضوع بيبقى معصبك وانت مش فاهم هو بيعمل كده ليه!
الحوار كله بقا هقولك عليه ...
تخيل إنك داخل على
bank.com (الموقع بتاع البنك بتاعك)، سجلت دخول، فالمتصفح حفظ Session Cookie 
دي ببساطة ورقة تعريف، أي طلب بعد كده للبنك هيعرف إنك إنت اللي عامل Login.
بعد شوية فتحت الإيميل ... ولقيت رسالة غريبة فيها لينك… طبعًا فضولك خلاك تدوس عليه
، اللينك ودّاك على attack.com.الموقع ده في الخلفية بعت طلب لـ
bank.com علشان يجيب بياناتك البنكية.الكارثة: البنك هيبعت البيانات عادي جدًا… لأنه شايف الكوكيز اللي بتقول إنك لسه داخل، فمش هيشك لحظة!
هنا بقى ظهر الـ SOP ...
المتصفحات قالت: "لأ، كده خطر".
فطلع قانون اسمه Same-Origin Policy.
معناه ببساطة:
أي طلب من موقع لموقع تاني مختلف في (البروتوكول + الدومين + البورت) هيترفض تلقائيًا
الموضوع ده حمى ناس كتير من هجمات زي CSRF… لكن!
فيه مشكلة…
المشكلة: مفيش APIs بقى شغالة!
إنت كـ developer، محتاج تجيب بيانات من مواقع تانية طول الوقت (مثلاً تسحب بيانات من API عام).
SOP هنا بيقفلك الباب خالص.
وهنا ظهر موضوع الCORS
إيه هو CORS بقى؟
لماexample.com يحاول يجيب بيانات من bank.com، المتصفح بيبعت Header اسمه Origin، بيقول للبنك الطلب جاي منين.لو البنك شايف إن
example.com موقع موثوق أو البيانات اللي بتتطلب عامة، بيرد بـ Header اسمه: Code:
Access-Control-Allow-Origin: http://example.comالمتصفح بقى يقرر: لو الرد مناسب → يكمل الطلب
لو مش مناسب → يوقفه ويطلعلك Error
طب إيه حكاية الـ Preflight؟
في طلبات معينة (زي PUT, DELETE أو فيها Headers خاصة)، المتصفح مايبعتهاش على طول…بيعمل حاجة اسمها Preflight Request، ودي بتكون OPTIONS request يسأل السيرفر:
"هو مسموح أعمل الطلب ده؟"
لو السيرفر وافق ورجع Headers زي:
Code:
Access-Control-Allow-Methods
Access-Control-Allow-Headersباختصار يا سيدي
ال CORS مش أداة سيرفر… ده Policy من المتصفح.
هدفه يحميك من المواقع اللي بتحاول تسرق بياناتك.
السيرفر بتاعك لازم يكون مهيّأ إنه يتعامل معاه.
الحماية دي مش 100%، ولازم تفضل حريص وانت بتتصفح.
