رؤوس HTTP الأمنية لحماية موقعك

ما رؤوس HTTP الأمنية ولماذا تهمّ؟

في كل مرة يطلب فيها متصفّح صفحة من خادمك، يردّ الخادم بجزأين: جسم الاستجابة (الـHTML والصور والسكربتات)، وترويسة الاستجابة (Response Headers) وهي أزواج من مفتاح وقيمة تصف الاستجابة وتوجّه سلوك المتصفّح. رؤوس HTTP الأمنية مجموعة محدّدة من هذه الترويسات تخبر المتصفّح بقواعد صارمة: «لا تحمّل سكربتات إلا من هذه المصادر»، «لا تعرض صفحتي داخل إطار في موقع آخر»، «تواصل معي عبر HTTPS فقط من الآن فصاعدًا». المتصفّح هو من ينفّذ هذه القواعد، فالحماية تحدث على جهاز الزائر لا على خادمك فقط.

أهميتها تنبع من مبدأ الدفاع في العمق (Defense in Depth): لا تعتمد على طبقة واحدة. قد يكون لديك جدار حماية ممتاز وكود نظيف، لكن ثغرة XSS واحدة في إضافة، أو خطأ في تنقية مُدخَل، كافية لحقن سكربت خبيث. هنا يأتي دور CSP كـشبكة أمان أخيرة تمنع المتصفّح من تنفيذ ذلك السكربت أصلًا. الرؤوس الأمنية لا تحلّ محلّ الكود السليم، لكنها تحدّ من الضرر عندما تفشل الطبقات الأخرى — وهذا بالضبط جوهر الأمان الجادّ.

ميزتها الإضافية أنها رخيصة جدًا: لا تتطلّب إعادة كتابة تطبيقك، بل أسطرًا قليلة في إعداد الخادم تُفعّل حماية تعمل على كل المتصفّحات الحديثة فورًا. الجدول التالي يلخّص الرؤوس السبعة الأساسية التي سنفصّلها، وهو مرجعك السريع لبقيّة المقال:

قبل أن نغوص في التفاصيل، لاحظ أن كل هذه الرؤوس تفترض أن موقعك يعمل أصلًا على HTTPS. إن لم تكن قد فعّلت الشهادة بعد، فابدأ من دليل تركيب شهادة SSL وتفعيل HTTPS، لأن رأس HSTS بلا معنى — بل خطر — على موقع لا يدعم HTTPS كاملًا.

HSTS — فرض HTTPS بلا تنازل

رأس Strict-Transport-Security، المعروف بـHSTS، هو أبسط الرؤوس وأكثرها فعاليّة. وظيفته: إخبار المتصفّح أنه يجب التواصل مع نطاقك عبر HTTPS حصرًا لمدّة محدّدة، فإن حاول أحد فتح http:// يحوّله المتصفّح تلقائيًا إلى https:// قبل إرسال أي طلب على الشبكة.

المشكلة التي يحلّها هي هجوم SSL Stripping: حتى لو كان موقعك يحوّل HTTP إلى HTTPS عبر إعادة توجيه 301، فإن الطلب الأوّل يخرج عبر HTTP غير المشفّر، ومهاجم في المنتصف (Man-in-the-Middle) يستطيع اعتراضه ومنع التحويل وإبقاء الضحية على اتصال غير آمن. HSTS يقطع هذا تمامًا لأن المتصفّح يتذكّر أنه لا يجب أن يلمس HTTP لهذا النطاق أصلًا. لفهم العلاقة العميقة بين HSTS ومصافحة TLS التي تؤمّن الاتصال، يساعد تصوّر ما يحدث في الكواليس:

معاملات HSTS الثلاثة

رأس HSTS يتكوّن من ثلاثة أجزاء، فهمها يجنّبك أخطر خطأ في الأمان: حبس زوّارك خارج موقعك.

القيمة الموصى بها للإنتاج:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

قائمة الـPreload ومخاطرها

عادةً يتعلّم المتصفّح قاعدة HSTS بعد أوّل زيارة ناجحة عبر HTTPS؛ تبقى نافذة صغيرة في الزيارة الأولى. قائمة الـPreload تسدّ هذه الثغرة: قائمة يصونها مشروع Chromium وتعتمدها المتصفّحات الكبرى، تحتوي نطاقات تُعامَل كـHTTPS-only منذ اللحظة الأولى دون أي زيارة سابقة. للانضمام تسجّل نطاقك على hstspreload.org.

لكن انتبه: الإدراج في القائمة شبه دائم. إزالة نطاق منها قد تستغرق أشهرًا وتنتشر مع تحديثات المتصفّحات ببطء. لذا لا تطلب preload إلا بعد التأكّد المطلق أن نطاقك الرئيسي وكل نطاقاته الفرعية ستبقى على HTTPS لسنوات. الخطأ الكلاسيكي: مطوّر يضيف preload ثم يكتشف أن نطاقًا فرعيًا (مثل legacy.example.com) لا يدعم HTTPS، فيصبح غير قابل للوصول نهائيًا حتى من المتصفّحات التي حمّلت القائمة.

نصيحة خبير: ابدأ بـmax-age قصير (مثل 300 ثوانٍ = 5 دقائق) عند أوّل تفعيل لـHSTS، راقب أن كل شيء يعمل، ثم ارفعه تدريجيًا إلى سنة. لا تضف includeSubDomains ولا preload إلا بعد التحقّق من كل نطاق فرعي.

Content-Security-Policy — درع ضدّ XSS

Content-Security-Policy (CSP) هو أقوى الرؤوس وأعقدها. يعطي المتصفّح قائمة بيضاء بالمصادر المسموح لها بتحميل المحتوى (سكربتات، أنماط، صور، خطوط، إطارات...). أي مورد خارج القائمة يرفض المتصفّح تحميله أو تنفيذه. بهذا، حتى لو نجح مهاجم في حقن <script src="https://evil.com/x.js"> عبر ثغرة XSS، فإن المتصفّح يرفض تحميله لأن evil.com ليس في القائمة البيضاء.

التوجيهات الأساسية

CSP يتكوّن من توجيهات (Directives)، كل توجيه يحكم نوعًا من الموارد. الجدول التالي يغطّي الأكثر استخدامًا:

الكلمات المفتاحية الخاصّة بين علامتي اقتباس مفردتين: 'self' (نفس الأصل)، 'none' (لا شيء)، 'unsafe-inline' (يسمح بالكود المضمَّن — تجنّبه)، 'unsafe-eval' (يسمح بـeval — تجنّبه)، 'nonce-XXX' و'sha256-XXX' (سنشرحهما).

مثال سياسة CSP متوازنة

سياسة بداية معقولة لموقع نموذجي:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://www.google-analytics.com;
  frame-ancestors 'self';
  base-uri 'self';
  form-action 'self';
  object-src 'none';
  upgrade-insecure-requests;

nonce وhash: التخلّص من unsafe-inline

أخطر تنازل في CSP هو 'unsafe-inline' في script-src، لأنه يبطل الحماية من XSS فعليًا (المهاجم يحقن سكربتًا مضمَّنًا فيُسمح له). البديلان النظيفان:

مع الـnonce، يولّد خادمك قيمة عشوائية فريدة لكل صفحة، يضعها في الرأس script-src 'nonce-r4nd0m' وفي وسم السكربت <script nonce="r4nd0m">. المهاجم لا يعرف القيمة العشوائية لطلب المستخدم، فلا يستطيع حقن سكربت مقبول. هذا هو المعيار الذهبي لـCSP حديث.

نمط Report-Only وتقارير الانتهاك

هنا أهمّ خدعة عملية: لا تفرض CSP فورًا. استخدم رأس Content-Security-Policy-Report-Only أولًا. بهذا الوضع، المتصفّح لا يحجب أي شيء، بل يرسل تقريرًا عن كل ما كان سيُحجَب إلى نقطة نهاية تحدّدها. تجمع هذه التقارير أسابيع، تكتشف منها كل المصادر المشروعة التي نسيتها (سكربت إعلانات، أداة دردشة، CDN خطوط...)، تضيفها للقائمة البيضاء، ثم — وفقط ثم — تبدّل الرأس إلى وضع الفرض.

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self';
  report-uri /csp-report-endpoint;
  report-to csp-endpoint;

نصيحة خبير: لا تنتقل أبدًا من «لا CSP» إلى «CSP مفروض» مباشرة على موقع إنتاج. المسار الآمن دائمًا: Report-Only → جمع → تعديل → فرض. هذا يحمي زوّارك من شاشة بيضاء مفاجئة.

موقع آمن يبدأ من استضافة آمنة

استضافة wpressly تأتيك بـSSL مجاني وحماية مدمجة ونسخ احتياطي تلقائي — أمّن موقعك وزوّارك من اليوم الأول.

اكتشف الاستضافة الآمنة

Clickjacking — X-Frame-Options مقابل frame-ancestors

هجوم Clickjacking يحمّل موقعك داخل <iframe> شفّاف فوق صفحة خبيثة، فيظنّ الضحية أنه ينقر زرًّا بريئًا بينما هو يضغط فعليًا على «تأكيد التحويل» أو «حذف الحساب» في موقعك المؤطَّر. الدفاع: أخبر المتصفّح من يُسمح له بتأطير موقعك.

توجد آليتان لذلك، واحدة قديمة وأخرى حديثة:

التوصية: استخدم كليهما للتوافق مع المتصفّحات القديمة جدًا، لكن اعلم أن frame-ancestors يسود حيثما دُعم. لمنع التأطير نهائيًا:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self'" always;

إن أردت منع التأطير من أي جهة على الإطلاق (لا حتى نفسك)، استخدم DENY وframe-ancestors 'none'. أمّا إن احتجت السماح لشريك محدّد فقط، فهذا حيث يتفوّق frame-ancestors 'self' https://partner.example.com لأن X-Frame-Options لا يدعم نطاقات متعدّدة.

X-Content-Type-Options: nosniff

هذا الرأس الصغير له قيمة واحدة: nosniff. وظيفته منع تخمين نوع المحتوى (MIME Sniffing). بعض المتصفّحات قديمًا كانت «تخمّن» نوع الملف بتفحّص محتواه بدل الاعتماد على رأس Content-Type. هذا خطر: مهاجم يرفع ملف صورة .jpg يحتوي فعليًا كود JavaScript، فيخمّنه المتصفّح كسكربت وينفّذه. مع nosniff يلتزم المتصفّح حرفيًا بنوع المحتوى المُعلَن ولا يخمّن.

add_header X-Content-Type-Options "nosniff" always;

القيمة دائمًا nosniff بلا استثناء، وهو رأس آمن تمامًا لا يكسر أي شيء عمليًا، فأضفه على كل موقع دون تردّد. شرطه الوحيد أن تكون رؤوس Content-Type على خادمك صحيحة أصلًا.

Referrer-Policy — لا تسرّب روابطك

عندما ينقر زائر رابطًا ينقله من صفحتك إلى موقع آخر، يرسل المتصفّح افتراضيًا رأس Referer يحوي عنوان الصفحة كاملًا الذي جاء منه. قد يكون هذا تسريبًا خطيرًا: تخيّل رابطًا في صفحة https://app.example.com/reset-password?token=secret123 — يصل الـtoken السرّي إلى الموقع الخارجي ضمن المُحيل. Referrer-Policy يضبط كمّ المعلومات التي تُرسَل.

القيمة الموصى بها هي الافتراضية في المتصفّحات الحديثة، لكن من الأفضل تعيينها صراحةً:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Permissions-Policy — كبح صلاحيات المتصفّح

كان اسمه سابقًا Feature-Policy، وأُعيدت تسميته إلى Permissions-Policy مع تغيير في الصياغة. وظيفته التحكّم في ميزات المتصفّح القويّة التي يمكن لصفحتك (أو أي إطار داخلها) استخدامها: الكاميرا، الميكروفون، الموقع الجغرافي، مستشعرات الحركة، الدفع، ملء الشاشة... المبدأ: عطّل كل ما لا تستخدمه، فإن حُقن سكربت خبيث لن يستطيع تشغيل الكاميرا أو قراءة الموقع.

الصياغة: قائمة مفصولة بفواصل، كل عنصر ميزة=(قائمة الأصول). قوسان فارغان () يعنيان تعطيلًا كاملًا، و(self) يعني السماح لنطاقك فقط:

add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), fullscreen=(self)" always;

عطّل بسخاء؛ يمكنك دائمًا السماح بميزة لاحقًا عند الحاجة الفعلية. هذا أبسط بكثير من تتبّع كل سكربت طرف ثالث قد يطلب صلاحية لا يحتاجها.

لمحة عن COOP وCOEP وCORP وCORS

هذه مجموعة رؤوس العزل عبر الأصول (Cross-Origin Isolation)، أحدث وأكثر تخصّصًا، نشأت ردًّا على هجمات قنوات جانبية مثل Spectre. أغلب المواقع لا تحتاجها، لكن من المفيد معرفتها:

تحتاج COOP وCOEP معًا (بقيمتي same-origin وrequire-corp) فقط إذا أردت تفعيل ميزات تتطلّب «عزلًا عبر الأصول» مثل SharedArrayBuffer أو قياس زمن دقيق. بالنسبة لمدوّنة أو متجر عادي، يكفيك إضافة Cross-Origin-Opener-Policy: same-origin كطبقة حماية إضافية خفيفة، وتأجيل البقيّة حتى تحتاجها فعلًا. أمّا CORS فهو موضوع منفصل يحكم وصول جافاسكربت لموارد نطاقات أخرى، ولا علاقة مباشرة له بحماية موقعك بقدر ما ينظّم واجهات الـAPI.

رؤوس مهجورة تجنّبها

ليست كل الرؤوس «الأمنية» القديمة مفيدة اليوم؛ بعضها صار ضارًّا أو عديم الجدوى:

القاعدة: إن وجدت X-XSS-Protection: 1; mode=block في إعدادك القديم، فاحذفه أو اضبطه 0، واعتمد على CSP. لا تضِف HPKP إطلاقًا — خطأ صغير فيه يحبس زوّارك خارج موقعك لشهور.

كيف تضيف الرؤوس حسب الخادم

طريقة إضافة الرؤوس تعتمد على بنيتك. الجدول يلخّص الخيارات، ثم نفصّل كلًّا منها:

Nginx

في Nginx تُضاف الرؤوس بتوجيه add_header. النقطة الحرجة التي يغفلها كثيرون: أضف الكلمة always في نهاية كل سطر، وإلا لن تُرسَل الرؤوس مع استجابات الأخطاء (404، 500...) وهي صفحات يمكن استغلالها أيضًا:

server {
    # ... باقي الإعداد ...

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "SAMEORIGIN" 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;
    add_header Content-Security-Policy "default-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'" always;
}

تحذير جوهري في Nginx: توجيه add_header لا يُورَّث إلى كتلة فرعية (مثل location) إن كانت تلك الكتلة تعرّف add_header خاصًّا بها — في تلك الحالة تختفي كل رؤوس الكتلة الأمّ. إن احتجت رؤوسًا داخل location معيّن، أعِد تعريف كل الرؤوس هناك، أو استخدم وحدة headers-more (more_set_headers) التي تتصرّف بمنطق مختلف. بعد التعديل، تحقّق دائمًا بـnginx -t ثم أعِد التحميل بـnginx -s reload.

Apache (.htaccess)

في Apache تُضاف عبر وحدة mod_headers بتوجيه Header set:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
    Header always set Content-Security-Policy "default-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'"
</IfModule>

لاحظ الكلمة always بعد Header لضمان إرسال الرؤوس حتى مع صفحات الأخطاء (نظير always في Nginx). تأكّد أن mod_headers مفعّلة (في كثير من الاستضافات المشتركة هي مفعّلة افتراضيًا). استخدم Header set للقيمة الجديدة، وHeader unset لإزالة رأس غير مرغوب (مفيد لحذف X-XSS-Protection المهجور).

Cloudflare وشبكات CDN

إن كنت خلف Cloudflare أو CDN، يمكنك إضافة الرؤوس على الحافة دون لمس خادمك، وهذا مريح لكنه قد يسبّب ازدواجية (سنناقشها في الأخطاء الشائعة). في Cloudflare:

اذهب إلى Rules ثم Transform Rules ثم Modify Response Header، وأنشئ قاعدة تنطبق على كل الطلبات (hostname يساوي نطاقك)، ثم أضف إجراء Set static لكل رأس باسمه وقيمته. يطبّق Cloudflare ذلك على كل استجابة تمرّ عبر شبكته. الميزة: تفعيل فوري على الحافة وحماية إضافية مع طبقات الحماية الأخرى للشبكة. لفهم كيف تتكامل هذه الطبقات معًا:

العيب الوحيد: إن أضاف خادمك الأصلي الرؤوس نفسها، تظهر مكرّرة. اختر مكانًا واحدًا فقط (الخادم أو الحافة) لكل رأس، أو فعّل خيار «overwrite» في Cloudflare ليستبدل بدل أن يضيف.

ووردبريس

أنظف طريقة لووردبريس هي إضافتها على مستوى الخادم (Nginx/Apache/CDN) لأنها أكفأ وتشمل كل الطلبات حتى الملفّات الثابتة. لكن إن لم تملك وصولًا للخادم (استضافة مشتركة بسيطة)، يمكن من functions.php في القالب الابن:

add_action( 'send_headers', function () {
    header( 'X-Frame-Options: SAMEORIGIN' );
    header( 'X-Content-Type-Options: nosniff' );
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
    header( 'Permissions-Policy: camera=(), microphone=(), geolocation=()' );
    header( "Content-Security-Policy: default-src 'self'; frame-ancestors 'self'; object-src 'none'" );
} );

عيب مقاربة التطبيق: لا تُطبَّق على الملفّات الثابتة التي يخدمها الخادم مباشرة (صور، CSS، JS)، ولا على صفحات الأخطاء، وتضيف حملًا بسيطًا على PHP. لذلك تبقى إضافتها على الخادم هي الأفضل دائمًا. بدلًا من تعديل الكود، توجد إضافات مخصّصة لإدارة الرؤوس إن كنت تفضّل واجهة رسومية. وبشكل عام، أمان ووردبريس أوسع من الرؤوس وحدها، فراجع دليل تأمين موقع ووردبريس لتضع هذه الرؤوس ضمن إستراتيجية حماية متكاملة.

موقع آمن يبدأ من استضافة آمنة

استضافة wpressly تأتيك بـSSL مجاني وحماية مدمجة ونسخ احتياطي تلقائي — أمّن موقعك وزوّارك من اليوم الأول.

اكتشف الاستضافة الآمنة

فحص الرؤوس والتحقّق منها

بعد الإضافة، لا تفترض النجاح — افحص. يمكنك أن تبدأ بـمحلّل ترويسات الأمان المجاني ليقيس مدى اكتمال رؤوس موقعك ويبرز النواقص في ثوانٍ، ثم تكمّل بأدوات مجانية أخرى تمنح موقعك درجة وتشرح النواقص:

للفحص اليدوي السريع من سطر الأوامر:

curl -sI https://example.com | grep -i -E 'strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy'

لا تطارد درجة A+ بأي ثمن؛ الدرجة وسيلة لا غاية. سياسة CSP صارمة فعليًا تستحقّ أكثر من علامة كاملة مع 'unsafe-inline' يبطل الحماية. اقرأ تفاصيل التقرير لا الحرف فقط.

خطة التفعيل التدريجي

تفعيل الرؤوس دفعة واحدة على موقع حيّ وصفة لكسره. اتبع هذه المراحل بالترتيب لتفعيل آمن:

المبدأ الحاكم: ابدأ بالآمن، أرجئ الخطر، راقب قبل تفعيل HSTS preload وCSP المفروض. هذا التدرّج يحوّل مهمّة مخيفة إلى سلسلة خطوات يمكن التراجع عن معظمها.

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

أكثر المشكلات تتكرّر بأنماط معروفة. هذا الجدول مرجعك عند ظهور خلل:

خطأ كسر الموقع بـCSP

هذا أخطرها: تنشر CSP مفروضًا فيختفي تنسيق الموقع أو تتعطّل الوظائف لأن المتصفّح حجب CSS أو JS مشروعًا. الوقاية: دائمًا Report-Only أولًا. العلاج الطارئ: حوّل الرأس فورًا إلى Content-Security-Policy-Report-Only (يوقف الحجب) أو احذفه مؤقّتًا، ثم افتح Console في DevTools لقراءة رسائل الانتهاك بدقّة — تخبرك بالضبط أي مورد حُجب وأي توجيه يلزم تعديله.

الرؤوس المكرّرة

عندما يضيف خادمك الأصلي رأسًا ويضيفه Cloudflare أيضًا، يستلم المتصفّح قيمتين. بعض الرؤوس (كـCSP) قد يعاملها المتصفّح بأخذ الأكثر تقييدًا، وبعضها يسبّب سلوكًا غير متوقّع. القاعدة: مصدر واحد لكل رأس. قرّر أين تدير الرؤوس (الخادم أو الحافة) والتزم به، أو فعّل خيار الاستبدال في الـCDN.

نسيان صفحات الأخطاء

صفحات 404 و500 استجابات حقيقية يمكن استغلالها (مثلًا تأطيرها في Clickjacking). إن نسيت always في Nginx أو Apache، تخرج هذه الصفحات بلا رؤوس حماية. تحقّق دائمًا بطلب صفحة غير موجودة وفحص رؤوسها.

تفعيل HSTS مبكّرًا

لا تفعّل HSTS — خصوصًا مع includeSubDomains وpreload — قبل أن يكون كل شيء على HTTPS بثبات. التفعيل المبكّر يحبس الزوّار خارج أي جزء لا يدعم HTTPS، والتراجع صعب لأن المتصفّح حفظ القاعدة. ابدأ بـmax-age صغير دائمًا. وتذكّر أن HSTS فرع من إستراتيجية أوسع لمقاومة الهجمات، تشمل مثلًا الحماية من DDoS على مستوى الشبكة.

نصائح خبير ختامية

• أتمتة لا نسيان: ضع الرؤوس في إعداد البنية التحتية (IaC) أو قالب الخادم، فلا تُنسى عند نشر خادم جديد.
• راقب باستمرار: أعِد الفحص بعد كل تحديث كبير أو إضافة أداة طرف ثالث؛ قد تكسر CSP فجأةً.
• وثّق سياسة CSP: علّق على كل توجيه ولماذا أُضيف مصدر، فالـCSP يتعفّن بسرعة بلا توثيق.
• لا تثق بالدرجة وحدها: A+ مع 'unsafe-inline' أضعف من B مع nonce حقيقي.
• اختبر على بيئة تجريبية: جرّب CSP المفروض على staging قبل الإنتاج كلما أمكن.

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

موقع آمن يبدأ من استضافة آمنة

استضافة wpressly تأتيك بـSSL مجاني وحماية مدمجة ونسخ احتياطي تلقائي — أمّن موقعك وزوّارك من اليوم الأول.

اكتشف الاستضافة الآمنة

الأسئلة الشائعة

هل رؤوس HTTP الأمنية تغني عن جدار الحماية وSSL؟ لا. هي طبقة مكمّلة ضمن الدفاع في العمق، لا بديل. تحتاج أولًا SSL/HTTPS فعّالًا (راجع تركيب شهادة SSL)، وجدار حماية، وكودًا نظيفًا، وتحديثات. الرؤوس تحدّ من الضرر عندما تفشل الطبقات الأخرى، خصوصًا CSP ضدّ XSS.

ما أهمّ رأس أبدأ به إن كان وقتي محدودًا؟ ابدأ بالثلاثة الآمنة التي لا تكسر شيئًا: X-Content-Type-Options: nosniff، وX-Frame-Options: SAMEORIGIN، وReferrer-Policy: strict-origin-when-cross-origin. أضِفها في دقائق ثم انتقل لاحقًا إلى HSTS وCSP بتدرّج.

هل تفعيل CSP قد يكسر موقعي؟ نعم إن فُرض دفعة واحدة دون اختبار، فقد يحجب CSS أو سكربتات مشروعة. لهذا استخدم Content-Security-Policy-Report-Only أولًا لأسابيع لجمع الانتهاكات وتعديل القائمة البيضاء، ثم بدّل إلى وضع الفرض بأمان.

ما الفرق بين X-Frame-Options وframe-ancestors؟ كلاهما يمنع Clickjacking بمنع تأطير موقعك. X-Frame-Options قديم ويدعم DENY أو SAMEORIGIN فقط، بينما frame-ancestors (توجيه في CSP) حديث ويدعم عدّة نطاقات موثوقة ويسود عند التعارض. استخدم كليهما للتوافق الأقصى.

هل أحتاج includeSubDomains وpreload في HSTS؟ ليس فورًا. أضِف includeSubDomains فقط بعد التأكّد أن كل نطاقاتك الفرعية تدعم HTTPS، وpreload فقط بعد التزام طويل الأمد بـHTTPS لأن إزالته من قائمة المتصفّحات صعبة وبطيئة جدًا.

لماذا تظهر رؤوسي مكرّرة؟ لأنها تُضاف من مصدرين: خادمك الأصلي والـCDN (مثل Cloudflare) معًا، أو الخادم والتطبيق معًا. اختر مصدرًا واحدًا لكل رأس، أو فعّل خيار «overwrite/replace» في الـCDN ليستبدل بدل أن يضيف.

هل ما زال X-XSS-Protection مفيدًا؟ لا، صار مهجورًا وأُزيل فلتره من المتصفّحات وقد يفتح ثغرات في حالات نادرة. اعتمد على CSP بدلًا منه، وإن وجدته في إعدادك القديم فاضبطه 0 أو احذفه.

كيف أفحص رؤوسي بعد الإضافة؟ استخدم securityheaders.com وMozilla Observatory للحصول على درجة وشرح، وGoogle CSP Evaluator لتقييم سياسة CSP تحديدًا، أو يدويًا عبر curl -sI https://yoursite.com أو تبويب Network في DevTools. اقرأ التفاصيل لا الدرجة فقط.

ما أفضل مكان لإضافة الرؤوس في ووردبريس؟ على مستوى الخادم (Nginx/Apache) أو الـCDN، لأنه أكفأ ويشمل الملفّات الثابتة وصفحات الأخطاء. إضافتها عبر functions.php أو إضافة ممكنة عند غياب وصول الخادم، لكنها لا تغطّي الموارد الثابتة وتضيف حملًا على PHP.

هل أضع الرؤوس على الخادم أم على Cloudflare؟ أيّهما أنسب لبنيتك، لكن اختر واحدًا لكل رأس لتجنّب الازدواجية. الحافة (Cloudflare Transform Rules) أسرع تفعيلًا وتطبّق قبل خادمك؛ الخادم يمنحك تحكّمًا دقيقًا ويعمل حتى دون CDN. لا تكرّر الرأس في الاثنين دون خيار الاستبدال.

هل أحتاج COOP وCOEP وCORP لموقعي؟ غالبًا لا. هذه رؤوس عزل متخصّصة تلزم فقط لميزات مثل SharedArrayBuffer أو قياس زمن دقيق. يكفي أغلب المواقع إضافة Cross-Origin-Opener-Policy: same-origin كطبقة خفيفة، وتأجيل البقيّة حتى تظهر حاجة فعلية لها.