Cross-Origin Resource Sharing (CORS)

From binaryoption
Jump to navigation Jump to search
Баннер1
    1. مشاركة موارد عبر المصادر (CORS)

مقدمة

في عالم الويب الحديث، غالباً ما تتطلب تطبيقات الويب بيانات من مصادر مختلفة. على سبيل المثال، قد يعرض تطبيق ويب يعمل على `example.com` صوراً مستضافة على `images.example.net` أو يتصل بواجهة برمجة تطبيقات (API) على `api.example.org`. تُعرف هذه السيناريوهات باسم الطلبات عبر المصادر (Cross-Origin Requests). لحماية المستخدمين من الهجمات الضارة، تفرض المتصفحات سياسة أصل واحد (Same-Origin Policy) بشكل افتراضي. تسمح مشاركة موارد عبر المصادر (CORS) للمتصفحات بتجاوز هذه السياسة بطريقة آمنة ومتحكم بها، مما يتيح لتطبيقات الويب الوصول إلى الموارد من نطاقات مختلفة.

يهدف هذا المقال إلى تقديم شرح شامل لـ CORS للمبتدئين، مع التركيز على المفاهيم الأساسية، وكيفية عمله، وكيفية تكوينه بشكل صحيح. سنغطي أيضاً بعض المشكلات الشائعة وحلولها. هذا الفهم ضروري لتطوير تطبيقات ويب آمنة وقابلة للتوسع.

سياسة الأصل الواحد (Same-Origin Policy)

قبل الغوص في CORS، من المهم فهم سياسة الأصل الواحد. تعتبر هذه السياسة حجر الزاوية في أمن الويب. ببساطة، تحدد سياسة الأصل الواحد أن المتصفح يجب أن يمنع تطبيقات الويب من طلب الموارد من نطاق مختلف عن النطاق الذي تم تحميل التطبيق منه. يُعتبر النطاق هو نفسه إذا كان له نفس البروتوكول (مثل HTTP أو HTTPS)، ونفس اسم المضيف (مثل `example.com`)، ونفس المنفذ (مثل 80 أو 443).

على سبيل المثال:

تهدف سياسة الأصل الواحد إلى منع موقع ويب ضار من الوصول إلى البيانات الحساسة الموجودة في موقع ويب آخر قام المستخدم بتسجيل الدخول إليه.

لماذا نحتاج إلى CORS؟

على الرغم من أن سياسة الأصل الواحد توفر مستوى أساسياً من الأمان، إلا أنها يمكن أن تكون مقيدة للغاية في بعض الحالات. العديد من تطبيقات الويب الحديثة تعتمد على واجهات برمجة تطبيقات (APIs) مستضافة على نطاقات مختلفة. على سبيل المثال:

  • تطبيق ويب يستخدم واجهة برمجة تطبيقات خرائط من Google Maps (مستضافة على نطاق Google).
  • تطبيق ويب يستخدم واجهة برمجة تطبيقات دفع من PayPal (مستضافة على نطاق PayPal).
  • تطبيق ويب يستخدم واجهة برمجة تطبيقات تحليلية من Mixpanel (مستضافة على نطاق Mixpanel).

بدون CORS، لن تتمكن هذه التطبيقات من الوصول إلى هذه الواجهات البرمجية، مما يحد من وظائفها بشكل كبير. لذلك، تم تطوير CORS لتوفير طريقة آمنة ومتحكم بها للسماح بالطلبات عبر المصادر.

كيف يعمل CORS؟

يعتمد CORS على آليتين رئيسيتين:

1. طلبات الاستكشاف (Preflight Requests): عندما يقوم المتصفح بإجراء طلب عبر المصادر يعتبر "معقداً" (Complex Request) (سيتم شرح أنواع الطلبات المعقدة لاحقاً)، فإنه يرسل أولاً طلباً يسمى "طلب الاستكشاف" (OPTIONS request) إلى الخادم المستهدف. يحتوي هذا الطلب على معلومات حول الطلب الفعلي الذي سيتم إرساله، مثل طريقة HTTP (GET, POST, PUT, DELETE) والرؤوس المخصصة. يتحقق الخادم بعد ذلك مما إذا كان يسمح بالطلب عبر المصادر. إذا كان الخادم يسمح بالطلب، فإنه يرسل استجابة تحتوي على رؤوس CORS التي تخبر المتصفح بالسماح بالطلب الفعلي. إذا لم يكن الخادم يسمح بالطلب، فسيقوم المتصفح بمنع الطلب الفعلي.

2. رؤوس HTTP CORS: تستخدم رؤوس HTTP الخاصة لإبلاغ المتصفح بسياسة CORS الخاصة بالخادم. تشمل رؤوس CORS المهمة ما يلي:

   *   Access-Control-Allow-Origin:  يحدد هذا الرأس النطاقات التي يُسمح لها بالوصول إلى المورد.  يمكن أن تكون القيمة نجمية (`*`)، مما يعني أن أي نطاق يُسمح له بالوصول إلى المورد (وهذا غير مستحسن في بيئات الإنتاج).  أو يمكن أن تكون قائمة بالنطاقات المسموح بها، مفصولة بمسافات.  مثال: `Access-Control-Allow-Origin: https://example.com https://www.example.com`
   *   Access-Control-Allow-Methods:  يحدد هذا الرأس طرق HTTP المسموح بها (مثل GET, POST, PUT, DELETE).  مثال: `Access-Control-Allow-Methods: GET, POST, OPTIONS`
   *   Access-Control-Allow-Headers:  يحدد هذا الرأس الرؤوس المخصصة المسموح بها في الطلبات عبر المصادر.  مثال: `Access-Control-Allow-Headers: Content-Type, Authorization`
   *   Access-Control-Allow-Credentials:  يحدد هذا الرأس ما إذا كان يُسمح بإرسال بيانات الاعتماد (مثل ملفات تعريف الارتباط) مع الطلبات عبر المصادر.  القيمة `true` تعني السماح، و `false` تعني الرفض.
   *   Access-Control-Max-Age:  يحدد هذا الرأس المدة (بالثواني) التي يمكن للمتصفح تخزين استجابة طلب الاستكشاف مؤقتاً.  يؤدي ذلك إلى تقليل عدد طلبات الاستكشاف التي يجب إرسالها.

أنواع الطلبات عبر المصادر

تقسم CORS الطلبات عبر المصادر إلى نوعين رئيسيين:

  • الطلبات البسيطة (Simple Requests): تعتبر هذه الطلبات بسيطة إذا استوفت الشروط التالية:
   *   الطريقة هي GET أو HEAD أو POST.
   *   إذا كانت الطريقة POST، يجب أن يكون نوع المحتوى `application/x-www-form-urlencoded` أو `multipart/form-data` أو `text/plain`.
   *   لا توجد رؤوس مخصصة.
   لا تتطلب الطلبات البسيطة طلب استكشاف.  يرسل المتصفح الطلب مباشرة إلى الخادم.  يجب على الخادم الرد برأس `Access-Control-Allow-Origin` المناسب.
  • الطلبات المعقدة (Complex Requests): أي طلب لا يستوفي شروط الطلبات البسيطة يعتبر طلباً معقداً. تتطلب الطلبات المعقدة طلب استكشاف قبل إرسال الطلب الفعلي.

تكوين CORS على الخادم

يعتمد كيفية تكوين CORS على الخادم الذي تستخدمه. فيما يلي بعض الأمثلة:

  • Apache: يستخدم ملف `.htaccess` لإضافة رؤوس CORS. مثال:
   ```apache
   <FilesMatch "\.(json|xml|html)$">
     Header set Access-Control-Allow-Origin "*"
     Header set Access-Control-Allow-Methods "GET, POST, OPTIONS"
     Header set Access-Control-Allow-Headers "Content-Type, Authorization"
   </FilesMatch>
   ```
  • Nginx: يستخدم ملف التكوين لإضافة رؤوس CORS. مثال:
   ```nginx
   add_header Access-Control-Allow-Origin *;
   add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
   add_header Access-Control-Allow-Headers "Content-Type, Authorization";
   ```
  • Node.js (Express): يستخدم وسيطة CORS لإضافة رؤوس CORS. مثال:
   ```javascript
   const express = require('express');
   const cors = require('cors');
   const app = express();
   app.use(cors()); // السماح بجميع المصادر
   app.get('/data', (req, res) => {
     res.json({ message: 'Hello, world!' });
   });
   app.listen(3000, () => {
     console.log('Server listening on port 3000');
   });
   ```

الأخطاء الشائعة وحلولها

  • خطأ CORS: "No 'Access-Control-Allow-Origin' header is present on the response." يعني هذا أن الخادم لم يرسل رأس `Access-Control-Allow-Origin` في استجابته. تأكد من تكوين الخادم بشكل صحيح لإضافة هذا الرأس.
  • خطأ CORS: "has been blocked by CORS policy." يعني هذا أن الخادم لم يسمح بالطلب عبر المصادر. تحقق من رؤوس CORS التي يرسلها الخادم وتأكد من أنها تسمح بالنطاق الذي تحاول إجراء الطلب منه.
  • مشاكل مع بيانات الاعتماد (Cookies): إذا كنت ترسل بيانات اعتماد (مثل ملفات تعريف الارتباط) مع طلبات CORS، فتأكد من أن الخادم يرسل رأس `Access-Control-Allow-Credentials: true` وأن النطاق الخاص بك ليس `*` في رأس `Access-Control-Allow-Origin`.

اعتبارات الأمان

على الرغم من أن CORS يوفر طريقة آمنة للسماح بالطلبات عبر المصادر، إلا أنه من المهم اتباع أفضل الممارسات لتجنب الثغرات الأمنية:

  • تجنب استخدام `*` في رأس `Access-Control-Allow-Origin` في بيئات الإنتاج. بدلاً من ذلك، حدد النطاقات المسموح بها بشكل صريح.
  • تحقق من صحة جميع البيانات التي تتلقاها من واجهات برمجة التطبيقات عبر المصادر. لا تثق أبداً في البيانات التي تأتي من مصادر غير موثوق بها.
  • استخدم HTTPS لجميع الاتصالات. يضمن HTTPS أن البيانات التي يتم إرسالها بين المتصفح والخادم مشفرة.

الخلاصة

CORS هو مفهوم أساسي في أمن الويب. يسمح لتطبيقات الويب بالوصول إلى الموارد من نطاقات مختلفة بطريقة آمنة ومتحكم بها. من خلال فهم كيفية عمل CORS وكيفية تكوينه بشكل صحيح، يمكنك تطوير تطبيقات ويب آمنة وقابلة للتوسع.

مواضيع ذات صلة

روابط إضافية (الخيارات الثنائية و تحليل السوق)

ابدأ التداول الآن

سجّل في IQ Option (الحد الأدنى للإيداع 10 دولار) افتح حساباً في Pocket Option (الحد الأدنى للإيداع 5 دولار)

انضم إلى مجتمعنا

اشترك في قناة Telegram الخاصة بنا @strategybin لتصلك: ✓ إشارات تداول يومية ✓ تحليلات استراتيجية حصرية ✓ تنبيهات اتجاهات السوق ✓ مواد تعليمية للمبتدئين

Баннер