Application Security

إتقان CORS: الدليل الشامل لتكوين تطبيقات الويب الآمنة

في مشهد تطوير الويب الحديث، لا تعد الاتصالات عبر النطاقات مجرد ميزة، بل هي مطلب أساسي. سواء كنت تبني تطبيق صفحة واحدة (SPA) مستضافاً على app.example.com يستهلك واجهة برمجة تطبيقات على api.example.com، أو تدمج خدمات مصغرة من أطراف ثالثة، فستواجه حتماً بروتوكول مشاركة الموارد عبر النطاقات (CORS). بينما صُمم CORS لحماية المستخدمين، لا يزال التكوين الخاطئ أحد أكثر مصادر الثغرات الأمنية وآلام التطوير شيوعاً. يوفر هذا الدليل غوصاً تقنياً شاملاً في كيفية تكوين CORS بشكل فعال وآمن وفعال.

فهم سياسة نفس الأصل

لتقدير أهمية CORS، يجب أولاً فهم سياسة نفس الأصل (SOP) في المتصفح. تعد SOP آلية أمان حاسمة تعزل المستندات التي قد تكون ضارة عن طريق تقييد كيفية تفاعل مستند أو نص برمجي محمّل من أصل معين مع مورد من أصل آخر. يُعرّف "الأصل" من خلال المخطط (scheme) والمضيف (host) والمنفذ (port) (على سبيل المثال، https://example.com:443).

عندما يبدأ المتصفح طلباً إلى أصل مختلف، فإنه لا يحظر الطلب outright، بل يتدخل في الاستجابة. إذا لم يمنح الخادم الإذن صراحةً عبر عناوين HTTP محددة، فإن المتصفح يحظر قراءة الاستجابة بواسطة النص البرمجي في جانب العميل. يمنع هذا المهاجمين من سرقة بيانات حساسة من نطاقات أخرى عبر نصوص برمجية خبيثة في صفحة تم اختراقها.

شرح عناوين CORS الرئيسية

يعمل CORS من خلال مجموعة من عناوين HTTP المتبادلة بين العميل والخادم. إليك العناوين الحاسمة التي تحتاج إلى إتقانها:

  • Access-Control-Allow-Origin (ACAO): يحدد النطاقات المسموح بها. يمكن أن يكون نطاقاً محدداً (https://frontend.com) أو رمزاً عالمياً (*).
  • Access-Control-Allow-Methods (ACAM): يدرج أساليب HTTP المسموح بها (GET, POST, PUT, DELETE، إلخ).
  • Access-Control-Allow-Headers (ACAH): يحدد العناوين التي يمكن استخدامها أثناء الطلب الفعلي (على سبيل المثال، Content-Type، Authorization).
  • Access-Control-Allow-Credentials (ACAC): قيمة منطقية تشير إلى ما إذا كان الطلب يمكن أن يتضمن بيانات اعتماد المستخدم مثل ملفات تعريف الارتباط (cookies)، وعناوين التفويض، أو شهادات عميل TLS.

من المهم ملاحظة أنه عندما يتم تعيين Access-Control-Allow-Credentials إلى true، لا يمكن استخدام الرمز العالمي * لـ Access-Control-Allow-Origin. سيقوم المتصفح برفض الاستجابة إذا تلقى رمزاً عالمياً لـ ACAO جنباً إلى جنب مع بيانات الاعتماد. هذه فخ شائع يواجهه المطورون الذين يحاولون تمكين المصادقة القائمة على الجلسة.

أمثلة تكوين عملية

لننظر في كيفية تكوين CORS في بيئة Node.js/Express النموذجية. يوضح هذا المثال إعداداً آمناً يتعامل ديناميكياً مع طلبات ما قبل الإرسال (preflight) ويحقق من صحة النطاقات مقابل قائمة بيضاء.

const express = require('express');
const app = express();

// تعريف النطاقات المسموح بها للتعامل الديناميكي
const allowedOrigins = ['https://frontend.example.com', 'https://admin.example.com'];

app.use((req, res, next) => {
  const origin = req.headers.origin;
  
  // التحقق مما إذا كان أصل الطلب موجوداً في القائمة المسموح بها
  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
  }

  // تحديد الأساليب والعناوين المسموح بها
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  
  // السماح ببيانات الاعتماد
  res.setHeader('Access-Control-Allow-Credentials', true);

  // التعامل مع طلبات ما قبل الإرسال
  if (req.method === 'OPTIONS') {
    return res.sendStatus(204);
  }

  next();
});

في هذا الجزء من الكود، نتجنب خطر الأمان الناتج عن استخدام * من خلال التحقق من صحة عنوان Origin الوارد مقابل قائمة بيضاء صارمة. كما نضمن عدم قدرة العميل على إرسال عناوين عشوائية من خلال سردها صراحةً في Allow-Headers. يتم التعامل مع فحص ما قبل الإرسال (طلب OPTIONS) بسلاسة لمنع المعالجة غير الضرورية لطلبات البيانات الفعلية.

أفضل الممارسات لتكوين CORS الآمن

  1. لا تستخدم الرموز العالمية مع بيانات الاعتماد: كما ذُكر سابقاً، فإن Access-Control-Allow-Credentials: true و Access-Control-Allow-Origin: * متنافيان في المتصفحات المتوافقة.
  2. قلل من النطاقات المسموح بها: استخدم دائماً قائمة بيضاء لنطاقات محددة بدلاً من فتح الوصول لجميع النطاقات.
  3. قيّد الأساليب والعناوين: اعرض فقط أساليب HTTP والعناوين التي تحتاجها واجهة برمجة التطبيقات الخاصة بك فعلياً. تزيد التكوينات المفرطة في الترخي من سطح الهجوم.
  4. عالج طلبات ما قبل الإرسال بشكل صحيح: تأكد من استجابة خادمك بـ 204 No Content أو 200 OK لطلبات OPTIONS دون تنفيذ منطق أعمالك.
  5. تجنب تخزين البيانات الحساسة في واجهات برمجة التطبيقات العامة: CORS هو سياسة يفرضها المتصفح. إنه لا يمنع طلبات HTTP المباشرة من الخوادم أو الأدوات مثل cURL. لذلك، لا تعتمد أبداً على CORS لحماية البيانات الحساسة على جانب الخادم؛ بل قم دائماً بتنفيذ مصادقة وتفويض مناسبين.

الخاتمة

يعد CORS أداة قوية تتيح التداخل المطلوب لتطبيقات الويب الحديثة، لكنه يتطلب تكويناً دقيقاً للحفاظ على الأمان. من خلال فهم الآليات الأساسية، واستخدام عناوين محددة، والالتزام بمبدأ الحد الأدنى من الامتيازات، يمكنك بناء تطبيقات قوية تكون وظيفية وآمنة في آن واحد. تذكر أن CORS هو مجرد طبقة واحدة من الدفاع؛ أكمله دائماً بمصادقة قوية، والتحقق من صحة المدخلات، وفحوصات التفويض على جانب الخادم.

Share: