CORS هي واحدة من أكثر الأجزاء سوء فهم في أمان الويب لأنها ترتبط عن كثب بالتحكم في الوصول دون أن تكون في الواقع تحكمًا بالوصول.
إنها تخبر المتصفح ما إذا كان من المسموح للكود الخاص بالواجهة الأمامية من أصل واحد قراءة استجابة من أصل آخر. هذا مفيد. ومع ذلك، ليس هو الشيء نفسه مثل تحديد ما إذا كان ينبغي السماح بالطلب في المقام الأول.
ماذا تفعل CORS
تؤثر CORS أساسًا على سلوك المتصفح:
- هل يمكن إجراء الطلب بشكل طبيعي؟
- هل يتسبب ذلك في إطلاق طلب مسبق؟
- هل يمكن تعريض الاستجابة لJavaScript الخاص بالواجهة الأمامية؟
لهذا السبب يمكن للخادم أن يتلقى طلبًا حتى لو قام المتصفح بعد ذلك بحظر الوصول إلى بيانات الاستجابة.
وهذا هو السبب أيضًا وراء عدم قيام CORS بأي شيء للعملاء غير المستندين إلى المتصفح مثل curl أو الخدمات الخلفية أو تطبيقات الهاتف المحمول. هؤلاء العملاء لا يفرضون قواعد أصل المتصفح في المقام الأول.
ما لا تفعله
CORS لا تحل محل:
- المصادقة
- التفويض
- حماية CSRF
- التحقق من صحة الجانب الخادمي
إذا كانت الحماية الوحيدة التي لديك هي "سوف يمنعها المتصفح بسبب CORS"، فالتصميم ليس آمنًا بما فيه الكفاية.
مثال ملموس
قد يكون إعداد الرأس هذا صحيحًا لتطبيق المتصفح:
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
ولكن لا يزال يحتاج واجهة برمجة التطبيقات الفعلية إلى التحقق مما إذا كان المتصل مصدقًا ومسموحًا له بتنفيذ الإجراء. CORS لا تجيب على هذا السؤال بالنيابة عنك.
قراءة إضافية