ترويسات أمان HTTP التي تستحق التفعيل فعلاً في 2026

قد يمتلك تطبيقك نظام مصادقة محكماً، وكلمات مرور مخزنة بتجزئة سليمة، وتقرير اختبار اختراق نظيفاً، ثم ينهار كل ذلك بسبب وسم <script> واحد محقون. ترويسات الأمان هي العقد الذي تفرضه على متصفح كل زائر ليحدّ من رقعة الضرر عندما يتسلل شيء ما عبر دفاعاتك. أغلب الفرق التي نلتقيها، من شركات ناشئة في تونس تخوض رقمنتها الأولى إلى منصات أكبر في الخليج، إما تتجاهل هذه الترويسات كلياً أو تلصق مقتطفاً منسوخاً من مدونة كتبت سنة 2018 وتعتبر الملف مغلقاً. الخياران خطأ، وفي 2026 أصبحت المسافة بين "لدينا ترويسات" و"لدينا ترويسات تعمل" هي المكان الذي تقع فيه الحوادث الحقيقية.

لماذا الترويسات أرخص وسيلة حماية تملكها

ترويسة الأمان سطر واحد في إعدادات الخادم يجنّد متصفح كل زائر كنقطة تنفيذ للسياسة. لا وكيل يُثبّت، ولا SDK يُضاف، ولا كلفة زمن استجابة تستحق القياس. المتصفح نفسه يرفض تحميل سكريبت المهاجم، ويرفض التراجع إلى HTTP غير المشفر، ويرفض أن تضع صفحة معادية صفحة الدفع الخاصة بك داخل إطار.

المشكلة أن الترويسات سياسة تصريحية، والسياسة التي لا يختبرها أحد تتعفن بصمت. نراجع في Innovation T عدداً كبيراً من تطبيقات الإنتاج لشركات تونسية وإقليمية، والنمط نفسه يتكرر في كل مرة: ترويسة Content-Security-Policy تحتوي unsafe-inline فتلغي نفسها بنفسها، وHSTS مفعّل على نطاق www دون النطاق الجذر، وترويسة X-Frame-Options مكررة ثلاث مرات من ثلاث طبقات بنية تحتية بقيم متناقضة. الترويسات كود، فعاملها كما تعامل الكود: نسخ موثقة، مراجعة، واختبارات في CI.

إليك إذن التصنيف الذي نستخدمه فعلياً: ماذا تفعل كل ترويسة على المستوى التقني، وكيف تنشر الصعبة منها دون كسر الإنتاج.

المستوى الأول: الترويستان اللتان توقفان هجمات حقيقية

Strict-Transport-Security (HSTS)

تغلق HSTS النافذة التي يكتب فيها المستخدم yourapp.tn فيرسل المتصفح طلب HTTP واحداً غير مشفر قبل إعادة التوجيه. ذلك الطلب الأول هو الموطن الطبيعي لهجمات SSL stripping: شبكة Wi-Fi مفتوحة في مقهى بوسط العاصمة، بوابات captive portal في المطارات والفنادق، أو مزود إنترنت لا سلطة لك عليه.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

آلية العمل: بمجرد أن يرى المتصفح هذه الترويسة عبر HTTPS، يعيد كتابة كل طلب HTTP مستقبلي نحو ذلك الأصل إلى HTTPS داخلياً، قبل أن يلمس أي شيء الشبكة، طوال مدة max-age بالثواني. ومع preload يمكنك تسجيل النطاق في قائمة التحميل المسبق لمشروع Chromium، فتنطبق الحماية حتى في أول زيارة على الإطلاق.

المقايضة التي يستهين بها كثيرون: الجمع بين includeSubDomains وpreload قرار شبه نهائي لا رجعة فيه عملياً. كل نطاق فرعي ستنشئه مستقبلاً يجب أن يقدم HTTPS صالحاً، إلى الأبد. تلك الأداة الداخلية على legacy.yourapp.tn بشهادة موقعة ذاتياً؟ ستصبح غير قابلة للفتح في كل متصفح سجّل السياسة. قاعدتنا: ابدأ بقيمة max-age=300 لأسبوع، ثم 86400، ثم سنة كاملة، ولا تسجل في preload إلا بعد جرد كل النطاقات الفرعية، بما فيها تلك التي أنشأها فريق التسويق لحملة موسمية ونسي إخبارك بها.

Content-Security-Policy (CSP)

CSP هي الترويسة الوحيدة التي تكبح فعلياً هجمات الحقن عبر المواقع (XSS)، وهي في الوقت نفسه الترويسة التي تخطئ فيها أغلب الفرق. سياسة تحتوي script-src 'unsafe-inline' أو قائمة سماح طويلة من نطاقات CDN ليست سوى مسرحية أمنية: قوائم السماح تُتجاوز بشكل روتيني عبر نقاط JSONP وإعادات التوجيه المفتوحة على النطاقات المسموح بها. أداة CSP Evaluator من Google تكشف هذه الثغرات في ثوانٍ، فمرر سياستك عليها قبل أن تثق بها.

ما ينجح في 2026 هو سياسة CSP صارمة مبنية على nonces مع strict-dynamic:

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
  frame-ancestors 'self';

آلية العمل: كل وسم <script> شرعي يحمل nonce يتغير مع كل استجابة. توجيه strict-dynamic يعني "أي سكريبت يحمّله سكريبت موثوق يصبح موثوقاً بدوره"، وهذا ما يجعل أدوات التجميع والاستيراد الديناميكي وأغلب مديري الوسوم قابلة للحياة تحت السياسة. أما https: وunsafe-inline في نهاية التوجيه فتتجاهلهما المتصفحات الحديثة، ووجودهما مجرد احتياط للمتصفحات العتيقة، فتفشل السياسة نحو السماح على أجهزة متحفية بدل أن تكسرها.

شرطان صارمان هنا. الأول: يجب أن يكون nonce عشوائياً تشفيرياً في كل استجابة، ما يعني أن HTML لا يمكن تخزينه كما هو في ذاكرة CDN المؤقتة. وإذا كنت تعتمد CDN عالمياً لتقريب المحتوى من زوارك في المنطقة، فستحتاج حقن nonce على الحافة، أو توليد الصفحات لكل طلب، أو سياسة مبنية على hash للمواقع الثابتة كلياً. الثاني: توجيه frame-ancestors مكانه هنا، فهو يعوّض X-Frame-Options بتحكم أدق، وهو الدفاع الفعلي ضد هجمات clickjacking.

CSP هي أيضاً جهاز الإنذار المبكر لسلسلة التوريد البرمجية. عندما يحاول سكريبت طرف ثالث مخترق، وليكن ويدجت دردشة أو بكسل تتبع، تهريب البيانات إلى نطاق جديد، فإن توجيه connect-src مشدوداً يحوّل اختراقاً صامتاً إلى تقرير انتهاك على لوحتك. وإذا كنت تحصّن بقية تلك السلسلة، فمقالنا عن بناء سلسلة DevSecOps متكاملة يشرح أين يوضع فحص الترويسات داخل CI.

المستوى الثاني: قيمة عالية بلا صداع

هذه الترويسات تستغرق دقائق ولا تكسر شيئاً تقريباً. فعّلها هذا الأسبوع.

X-Content-Type-Options

X-Content-Type-Options: nosniff

تمنع المتصفح من تخمين أنواع MIME، وهو ما يقتل فئة كاملة من الهجمات التي تُفسَّر فيها "صورة" مرفوعة على أنها سكريبت. وهي أيضاً شرط لكي تعمل كثير من حمايات المتصفحات الحديثة بكامل طاقتها. لا يوجد أي سبب مشروع لإغفالها.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

المتصفحات تعتمد هذه القيمة افتراضياً اليوم، لكن اضبطها صراحة حتى لا يعيدك وسيط proxy أو عميل قديم إلى الوراء. سيناريو الفشل الذي تمنعه قبيح: عناوين URL كاملة، تحمل أحياناً رموز إعادة تعيين كلمة المرور أو معرفات جلسات في سلاسل الاستعلام، تتسرب إلى كل نطاق طرف ثالث تحمّل منه موارد. وبما أن كثيراً من الشركات في منطقتنا ترسل روابط الاستعادة عبر البريد أو WhatsApp، فإن أي رمز حساس في URL يستحق معاملة خاصة: فكّر في no-referrer على تلك المسارات تحديداً.

Permissions-Policy

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), browsing-topics=()

منع افتراضي لواجهات المتصفح القوية. القصد ليس أن كودك سيطلب فجأة الوصول إلى الكاميرا، بل أن أي سكريبت طرف ثالث مخترقاً مدمجاً في صفحتك يرث صلاحياتك. رفض كل ما لا تستخدمه يحوّل سيناريو "مهاجم داخل iframe إعلاني يشغّل المستشعرات" إلى لا شيء. وكمكسب إضافي، browsing-topics=() يُخرج مستخدميك من واجهات التتبع القائم على الاهتمامات، وهي نقطة ثقة صغيرة لصالحك.

ثلاثي عزل Cross-Origin: COOP وCOEP وCORP

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-site

وُجدت هذه الترويسات بسبب هجمات من عائلة Spectre: أي بيانات تُحمَّل داخل عمليتك يمكن نظرياً أن يقرأها كود مهاجم يعمل في العملية نفسها. COOP تقطع مرجع window بين صفحتك والصفحات التي تفتحها، وهو ما يقتل أيضاً فئة من هجمات tab-nabbing. COEP تشترط أن يعلن كل مورد مدمج صراحة موافقته على الإدماج. وCORP هي إشارة تلك الموافقة لمواردك أنت.

مقايضة بصراحة: COEP مع require-corp ستكسر الصور والإطارات والويدجت الخارجية التي لا ترسل ترويسات CORP، ومنها أزرار الدردشة وخرائط مدمجة تجدها في أغلب مواقع الشركات المحلية، وتتبّع الأعطال فيها عمل مضنٍ. إذا كنت تعالج بيانات دفع عبر بوابات الدفع الإلكتروني، أو بيانات صحية، أو تشغّل أي شيء يحتاج SharedArrayBuffer، فاستثمر في هذا العمل. أما لموقع محتوى، فإن COOP: same-origin وحدها نقطة توقف معقولة.

ترويسات يجب حذفها في 2026

المقتطفات القديمة تحمل وزناً ميتاً، وبعضه مؤذٍ فعلاً:

• X-XSS-Protection: المرشح الذي كانت تتحكم فيه أُزيل من كل المتصفحات الكبرى منذ سنوات، بل كان المرشح نفسه في المتصفحات القديمة بوابة لتسريب المعلومات. لا تضبط شيئاً، أو اضبط 0 إذا ألحّ عليك ماسح أمني.
• Expect-CT: انتهى زمنها. شفافية الشهادات Certificate Transparency إلزامية في المتصفحات منذ سنوات.
• X-Frame-Options: عوّضها frame-ancestors. أبقها فقط إذا كنت تدعم فعلاً عملاء من عصور سابقة، وتأكد أنها لا تناقض سياسة CSP لديك.
• X-Powered-By وقيم Server المفصّلة: ليست ترويسات أمان أصلاً، لكن احذفها على أي حال. استطلاع مجاني للمهاجمين، وقيمة صفرية لك.

نشر CSP دون كسر الإنتاج

هذا هو الجزء الذي تتجاوزه كل الأدلة. إليك التسلسل الذي ننفذه في مشاريع عملائنا:

1. اجرد الواقع أولاً. انشر Content-Security-Policy-Report-Only بسياستك الصارمة المستهدفة مع نقطة استقبال للتقارير. لا شيء يُحظر بعد؛ أنت فقط تجمع الانتهاكات من حركة مرور حقيقية، بما فيها بكسلات التسويق وويدجت الدردشة التي لم يوثقها أحد.
2. اربط التقارير بشكل سليم. استخدم ترويسة Reporting-Endpoints الحديثة ووجّه report-to إليها. استضف المجمّع بنفسك أو استخدم خدمة؛ المهم أن تصل التقارير إلى نفس المكان الذي تصل إليه بقية تنبيهاتك.
3. صنّف الانتهاكات لأسبوعين إلى أربعة. الانتهاكات الحقيقية تتجمع بسرعة: إضافات المتصفحات (ضجيج، تجاهلها)، حقن مدير الوسوم (تُصلح بتمرير nonce)، ومعالجات inline قديمة مثل onclick= (أعد كتابتها، وهذا عادة الجزء الأكبر من العمل).
4. أصلح التطبيق، لا السياسة. كلما راودتك فكرة توسيع السياسة، اسأل نفسك إن كان الكود هو ما يجب أن يتغير. إضافة unsafe-inline "مؤقتاً" إضافة دائمة. لم نرها تُزال لاحقاً ولا مرة واحدة.
5. فعّل الفرض على مسار منخفض المخاطر أولاً. حوّل Report-Only إلى فرض على صفحاتك التسويقية أو على أداة داخلية. راقب معدلات الأخطاء والتقارير لأسبوع.
6. افرض في كل مكان، وأبقِ Report-Only يعمل. شغّل الترويستين جنباً إلى جنب: السياسة المفروضة أرضيتك، ومرشح Report-Only الأكثر صرامة هو نسختك القادمة. هكذا تشدّ السياسة تدريجياً مع الوقت دون مقامرة.
7. أضف اختبار انحدار. خطوة CI تجلب المسارات الرئيسية وتتحقق من الترويسات تُكتب في ساعة واحدة. وستوفر عليك حادثة الثانية فجراً حين تُسقط هجرة CDN بصمت كل ترويسة نشرتها.

هذه الخطوة الأخيرة أهم من أي ترويسة منفردة. في خبرتنا، انحدارات الترويسات تحدث عند حدود البنية التحتية: reverse proxy جديد، تغيير CDN، هجرة منصة. لا أحد يلاحظ لأشهر لأن لا شيء ينكسر بشكل مرئي. التحقق مكانه سلسلة النشر، لا ذاكرة أحدهم. وهي نفس الحجة التي نسوقها في مقالنا عن أمان واجهات API: وسيلة الحماية التي لا تتحقق منها باستمرار غير موجودة أصلاً.

أين تضبطها، وكيف تتحقق منها

اضبط الترويسات عند الطبقة الخارجية الأبعد التي تتحكم فيها، مرة واحدة. القيم المتضاربة من طبقات متعددة تنتج سلوك متصفح غريباً فعلاً، ومع CSP تتحد الترويسات المتعددة بالتقاطع، ما يعني عادة "الأشد صرامة يفوز" بطرق لم يقصدها أحد.

على حافة nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

علامة always جوهرية: بدونها يسقط nginx ترويساتك على استجابات 404 و500، وهي بالضبط الاستجابات التي يسبر بها المهاجمون موقعك. أما CSP المبنية على nonces فلا مكان لها في إعدادات ثابتة؛ ولّدها لكل طلب داخل التطبيق أو في edge worker.

أدوات التحقق التي تستحق مكانها: Mozilla Observatory وsecurityheaders.com للنظرة من الخارج، وCSP Evaluator من Google لجودة السياسة، وحلقة curl في CI لرصد الانحدارات. لكن لمطاردة العلامات نمط فشل معروف: تقييم A+ مع سياسة CSP تلغي نفسها أسوأ من B مع سياسة حقيقية، لأنه يصنع ثقة زائفة. الماسحات تفحص الوجود، لا الصحة. وهذه بالضبط الفجوة التي صُمم اختبار الاختراق الاحترافي لكشفها.

إطار قرار حسب نوع التطبيق

• موقع تسويقي ثابت: HSTS، nosniff، Referrer-Policy، Permissions-Policy، وسياسة CSP مبنية على hash مع frame-ancestors. نصف يوم عمل، ومخاطرة شبه معدومة.
• لوحة تحكم SaaS: كل ما سبق إضافة إلى CSP صارمة قائمة على nonces مع تقارير، وCOOP. خصص ثلاثة إلى ستة أسابيع تقويمية لنشر CSP، أغلبها انتظار لبيانات Report-Only.
• fintech والصحة وكل نشاط خاضع للرقابة: الحزمة الكاملة بما فيها عزل COEP/CORP، وتوجيه connect-src مشدود، وتأكيدات الترويسات في CI كبوابة إصدار. تصبح الترويسات جزءاً من أدلة الامتثال التي تقدمها للجهات الرقابية وهيئات حماية المعطيات الشخصية.
• منتج ويدجت مدمج: أنت هنا على الجهة الأخرى من الطاولة. أرسل ترويسات CORP صحيحة، وصمم لتعمل تحت سياسات CSP لدى عملائك، ووثّق التوجيهات الدقيقة التي يحتاجها المدمجون.

القاعدة الجامعة: كل ترويسة تفرض حداً، وعليك أن تعرف أي حد تحرسه كل واحدة. إذا لم يستطع أحد في الفريق تفسير سبب وجود ترويسة ما، فهي إما وزن ميت أو عطل كامن ينتظر لحظته.

كيف تساعدك Innovation T

تبني Innovation T منصات ويب وتحصّنها لعملاء في أوروبا وشمال إفريقيا: نشر سياسات CSP صارمة على منتجات حية، وعزل Cross-Origin لتطبيقات عالية الحساسية، وسلاسل CI تعامل ترويسات الأمان ككود مختبر. خضنا مرحلة تصنيف Report-Only مرات كافية لنضغط أسابيع من التخمين في عملية قابلة للتنبؤ.

إذا كانت آخر مراجعة لترويساتك مجرد مقتطف منسوخ، اطلع على ما تغطيه خدماتنا الهندسية والأمنية أو تحدث إلينا حول تدقيق أمني. الجولة الأولى تستغرق عادة أياماً لا أشهراً، وهي أرخص تقليص لسطح الهجوم ستشتريه هذا العام.