Technical Tutorials

في النظام البيئي الحديث للخدمات المصغرة وتطبيقات الصفحة الواحدة (SPAs)، أصبح مشاركة الموارد عبر النطاقات (CORS) أحد أكثر المكونات سوء فهمًا وحسمًا في أمان الويب. إذا واجهتَ يومًا رسالة خطأ محيرة في وحدة تحكم المتصفح تنص على "تم حظر الوصول إلى جلب البيانات من... من قبل سياسة CORS"، فأنت لست وحدك. يهدف هذا الدليل إلى تبسيط مفهوم CORS، وشرح آليات الأمان الأساسية، وتقديم استراتيجيات تكوين قوية للمطورين.

فهم سياسة النطاق نفسه (Same-Origin Policy)

لفهم سبب وجود CORS، يجب علينا أولاً النظر في سياسة النطاق نفسه (SOP). تفرض المتصفحات سياسة SOP لعزل المستندات التي قد تكون ضارة. يُعتبر أصلان متماثلين إذا كانا يتشاركان في نفس البروتوكول، والمضيف (النطاق)، والمنفذ. تمنع SOP سكريبتًا محملاً من https://app.example.com من قراءة البيانات من https://api.example.com ما لم يُسمح بذلك صراحةً.

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

تشريح طلب CORS

عندما يقوم المتصفح بإجراء طلب عبر النطاقات، فإنه يعمل كبوابة تفتيش. يفحص رؤوس الاستجابة القادمة من الخادم لتحديد ما إذا كان يجب السماح بالطلب. هناك نوعان من الطلبات: بسيطة وطلبات مسبقة (preflight).

الطلبات البسيطة لا تتطلب أي اتصال مسبق. وهي طلبات GET أو POST بأنواع محتوى قياسية (مثل application/x-www-form-urlencoded أو multipart/form-data). يرسل المتصفح الطلب مع رأس Origin يوضح مصدر الطلب.

طلبات ما قبل التنفيذ (Preflight Requests) تحدث عندما تكون طريقة الطلب هي DELETE أو PUT أو PATCH، أو عند استخدام رؤوس مخصصة (مثل X-Custom-Header) أو أنواع محتوى غير قياسية. في هذه الحالات، يرسل المتصفح طلب OPTIONS أولاً للسؤال الخادم: "هل من الجيد إذا أرسلت هذا الطلب الفعلي؟" فقط إذا استجاب الخادم برؤوس ومنهجيات مسموحة محددة، يواصل المتصفح تنفيذ الطلب الفعلي.

شرح رؤوس CORS الرئيسية

يعتمد التكوين على ضبط رؤوس HTTP بشكل صحيح. إليك أهمها:

Access-Control-Allow-Origin: يحدد النطاقات المسموح بها. يسمح استخدام * بجميع النطاقات، لكن هذا غالبًا ما يُنصح بعدم استخدامه لواجهات برمجة التطبيقات التي تتطلب مصادقة.
Access-Control-Allow-Methods: يسرد طرق HTTP المسموح بها (مثل GET، POST، OPTIONS).
Access-Control-Allow-Headers: يحدد الرؤوس التي يمكن استخدامها في الطلب الفعلي.
Access-Control-Allow-Credentials: إذا تم تعيينه على true، يسمح بإرسال ملفات تعريف الارتباط ومعلومات المصادقة مع الطلب.

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

فيما يلي أمثلة حول كيفية تكوين CORS في أطر عمل الخلفية الشائعة. تذكر أن الهدف هو أن تكون مقيدًا قدر الإمكان، والسماح فقط بما هو ضروري.

Node.js مع Express

استخدام وسيط cors هو النهج القياسي. لواجهات برمجة التطبيقات في بيئة الإنتاج، تجنب استخدام الرموز النجمية (*) إذا كنت بحاجة إلى دعم بيانات الاعتماد.

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

// السماح فقط بنطاقات محددة
const corsOptions = {
  origin: ['https://frontend.example.com', 'http://localhost:3000'],
  optionsSuccessStatus: 200, // بعض المتصفحات القديمة تواجه مشاكل مع 204
  credentials: true // يسمح بإرسال ملفات تعريف الارتباط
};

app.use(cors(corsOptions));

Python مع Flask

يُسهّل الامتداد flask-cors هذه العملية بشكل كبير.

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
# تقييد النطاق بنطاق محدد
CORS(app, origins=["https://frontend.example.com"])

@app.route('/data')
def get_data():
    return {'message': 'بيانات مؤمنة'}

المزال الشائعة وأفضل الممارسات

أحد أكثر الأخطاء شيوعًا هو تمكين Access-Control-Allow-Credentials: true بينما يتم تعيين Access-Control-Allow-Origin: * في الوقت نفسه. هذا المزيج غير صالح وفقًا لمواصفة CORS. عندما تكون بيانات الاعتماد متورطة، يجب عليك تحديد النطاق الدقيق.

من المزال الأخرى هي سوء معالجة طلبات ما قبل التنفيذ. تأكد من أن خادمك يعيد حالة 204 No Content أو 200 OK لطلبات OPTIONS. إذا فشلت طلبات ما قبل التنفيذ، فلن يتم إرسال الطلب الفعلي أبدًا، مما يؤدي إلى أخطاء محيرة.

أخيرًا، ضع دائمًا وضعك الأمني في الاعتبار. قم بمراجعة تكوينات CORS بانتظام. إذا كان لديك خدمة لا تحتاج إلى وصول عبر النطاقات، فتعطيل CORS تمامًا أو قيده على localhost فقط. يمكن أن يوفر تنفيذ سياسة أمن المحتوى (CSP) أيضًا طبقة إضافية من الدفاع ضد أنواع معينة من الهجمات.

الخاتمة

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