NestJS — Node.js للمؤسسات

CORS و Helmet و CSRF والضغط

18 دقيقة الدرس 58 من 80

CORS و Helmet و CSRF والضغط

الأمان وتقوية HTTP ليسا مفتاحاً واحداً. يجمع تطبيق NestJS عادة بين سياسة CORS، ورؤوس Helmet، وحماية CSRF لتدفقات المتصفح المعتمدة على الكوكيز، وخيارات ضغط حذرة.

الفكرة الأساسية

تدور هذه الميزة حول التحكم في كيفية تنظيم التطبيق وسلوكه وقت التشغيل. النقاط التالية هي ما يجب أن يعرفه المطور قبل استخدامها في مشروع حقيقي:

يتحكم CORS في الأصول التي تستطيع استدعاء API من المتصفحات؛ وهو ليس نظام مصادقة.
يضبط Helmet رؤوس أمان شائعة، لكن سياسة أمان المحتوى تحتاج ضبطاً خاصاً بالتطبيق.
تهم CSRF عندما يرفق المتصفح بيانات اعتماد تلقائياً مثل الكوكيز.
يقلل الضغط حجم الاستجابة لكن يمكن نقله إلى Nginx أو CDN أو بوابة API في الأنظمة عالية الحركة.
يستخدم Fastify إضافات مختلفة عن Express لعدد من هذه الأمور.

مثال عملي

يوضح المثال التالي الشكل العملي للفكرة داخل مشروع NestJS. ليست الغاية حفظ الكود، بل فهم مكانه في المعمارية:

const app = await NestFactory.create(AppModule);

app.enableCors({
  origin: ['https://app.example.com'],
  credentials: true,
  methods: ['GET', 'POST', 'PATCH', 'DELETE'],
});

app.use(helmet({
  contentSecurityPolicy: {
    directives: { defaultSrc: ["'self'"], scriptSrc: ["'self'"] },
  },
}));

app.use(compression());

ملاحظة تصميمية: تعامل مع وسيطات الأمان كطبقة سياسة. الإعداد الأكثر أماناً غالباً هو أصول محدودة، وطرق صريحة، وخصائص كوكيز صارمة، وCSP مختبرة على الواجهة الفعلية.

قائمة تطبيق إنتاجية

اسمح بأصول محددة بدلاً من CORS عام مع بيانات الاعتماد.
اضبط CSP في Helmet بعد فحص مصادر السكربتات والأنماط والخطوط والصور.
استخدم رموز CSRF للطرق غير الآمنة المعتمدة على الكوكيز.
تجنب الضغط داخل التطبيق عندما يضغط الوكيل العكسي الاستجابات أصلاً.

قاعدة عملية: إذا جعلت الميزة الحدود أوضح والاختبارات أسهل فهي اختيار جيد. إذا أخفت التبعيات أو صعّبت التتبع، فأعد التصميم.

الخلاصة

يغطي هذا الدرس جزءاً متقدماً من NestJS يجب فهمه عند بناء تطبيقات مؤسسية. ركّز على الحدود الواضحة، والسلوك القابل للاختبار، واختيار الأداة المناسبة للسياق بدلاً من استخدام كل ميزة في كل مكان.