كيفية إضافة رؤوس أمان HTTP في WordPress

WordPress هو نظام إدارة المحتوى (CMS) الأكثر شيوعًا في العالم ، حيث يشغل أكثر من 43٪ من جميع مواقع الويب على الإنترنت.ومع ذلك ، فإن استخدامها على نطاق واسع يجعلها هدفًا شائعًا للمتسللين.

تساهم هجمات القوة الغاشمة ونقاط ضعف تحميل الملفات وهجمات البرمجة عبر المواقع في التهديد المستمر.

لحسن الحظ ، هناك عدة طرق لجعل موقع الويب الخاص بك أكثر أمانًا وأقل عرضة للهجمات. وهنا تظهر رؤوس HTTP في الصورة.

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

في هذه المقالة ، سنناقش ماهية رؤوس أمان HTTP وكيف يمكنك تنفيذها بفعالية على موقع الويب الخاص بك.

ما هي رؤوس أمان HTTP بالضبط؟

رؤوس أمان HTTP هي مجموعة من التوجيهات التي تستخدمها تطبيقات الويب لتنفيذ دفاعات الأمان في متصفحات الويب. يتم تبادل هذه الرؤوس بين مستعرض الويب (العميل) والخادم لتحديد معلمات الأمان لاتصال HTTP. هذا التبادل للمعلومات يخبر المتصفح بكيفية التصرف خلال تفاعلاته مع موقعك ، ويحكم العمليات مثل عرض الأخطاء وإدارة ذاكرة التخزين المؤقت.

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

ومع ذلك ، فإن شاغلنا الأساسي هو أن رؤوس أمان HTTP تمنع موقع الويب الخاص بك من الهجمات الشائعة مثل البرمجة النصية عبر المواقع وهجمات القوة الغاشمة.تتمثل أكثر الطرق فعالية لتنفيذ هذه الرؤوس في تعيينها على حساب استضافة WordPress الخاص بك (مستوى الخادم) واستخدام جدار حماية لتطبيق موقع الويب على مستوى DNS مثل Cloudflare.

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

قبل مناقشة الطرق المختلفة لإضافة رؤوس الأمان ، دعنا نلقي نظرة على كل رأس بالتفصيل ونفهم سبب أهميته.إذا كنت بالفعل على دراية برؤوس الأمان ، فيمكنك التخطي إلى القسم أدناه.

أنواع رؤوس أمان HTTP في WordPress

هناك العديد من رؤوس أمان HTTP التي يمكن استخدامها مع موقع WordPress الخاص بك لتعزيز الحماية. دعنا نلقي نظرة على بعض أهمها.

1. رأس أمان حماية X-XSS

يتم استخدام رأس الأمان هذا لتكوين البرمجة النصية عبر المواقع (XSS) ، وهي ثغرة أمنية تسمح لأطراف ثالثة غير مصادق عليها بتنفيذ تعليمات برمجية نيابة عن موقع ويب آخر في المستعرض.

يمنع العديد من هجمات XSS على موقع الويب الخاص بك عن طريق منع الموقع من العرض إذا تم اكتشاف هجوم. يستخدم X-XSS الخيار الأكثر أمانًا لعدم تحميل الموقع تمامًا بدلاً من محاولة تطهير الصفحة عن طريق استبدال العناصر التي قد تكون ضارة.

يمكن أن يحتوي الرأس على إحدى هذه القيم العديدة:

• X-XSS-Protection: 0 يعطل تصفية XSS (غير مستحسن)
• X-XSS-Protection: 1 لتمكين تصفية XSS ، والتي عادة ما تكون الافتراضية في معظم المتصفحات. إذا تم اكتشاف هجوم XSS ، فسيقوم المتصفح بإزالة الأجزاء غير الآمنة من الصفحة (التعقيم).
• حماية X-XSS: 1 ؛ mode = block لتمكين تصفية XSS ، ولكن بدلاً من تطهير الصفحة ، سيمنع المستعرض عرض الصفحة (مستحسن)
• حماية X-XSS: 1 ؛ report = <reporting-uri> يُمكّن تصفية XSS. سيقوم المستعرض بتعقيم الصفحة والإبلاغ عن الانتهاك إذا تم اكتشاف هجوم نصي عبر المواقع.

2. رأس أمان خيارات الإطار X

يمكن استخدام رأس الأمان X-Frame-Options لمنع هجمات القوة الغاشمة المختلفة وهجمات DDOS ، ولكن الاستخدام الأكثر فاعلية له هو ضد اختراق إطارات iframe وغطاء النقر فوق موقع الويب الخاص بك على WordPress.يسمح لك هذا العنوان بتحديد ما إذا كان يمكن تضمين صفحة على موقع الويب الخاص بك باستخدام عناصر iframe في المتصفح أم لا.

يحمي خيار X-Frame موقع الويب الخاص بك من النقر فوق السرقة عن طريق منع ملء إطارات iframes بموقعك. له توجيهان مختلفان يمكنك الاختيار من بينهما -DENY و SAMEORIGIN. إنه يعمل مع جميع متصفحات الويب الشائعة ، مثل Chrome و Safari و Firefox و Opera.

 X- خيارات الإطار: حرمان

 خيارات الإطار X: SAMEORIGIN

عند تحديده بـ DENY ، سيتسبب رأس X-Frame-Options في حدوث فشل في حالة محاولة أي مستعرض تحميل الصفحة داخل إطار عند تحميلها من مواقع أخرى. ستفشل أيضًا محاولات القيام بذلك عند تحميلها في إطار iframe من الموقع الأصلي. من ناحية أخرى ، إذا حددنا SAMEORIGIN ، فلا يزال بإمكاننا استخدام الصفحة داخل إطار - طالما أن الموقع الذي يتضمنه في إطار هو نفسه الذي يخدم الصفحة.

هذا العنوان مهم بشكل خاص لصفحات الويب التي تحتوي على معلومات حساسة وصفحات تتضمن معلومات مثل بوابات الدفع والنماذج.

3. رأس HTTP Strict Transport Security (HSTS)

HTTP Strict-Transport-Security عبارة عن رأس استجابة أمنية يتم إرسالها من خادم ويب إلى متصفح الويب الخاص بالمستخدم لإبلاغه بأنه يجب الوصول إلى الموقع فقط باستخدام HTTP وليس عبر HTTP غير المشفر مطلقًا.

يوفر هذا الرأس آلية لفرض استخدام HTTPS بواسطة المتصفح ، حتى إذا كتب المستخدم "http: //" في شريط العناوين أو يتبع ارتباط HTTP.يمكنه أيضًا منع المستخدمين من تجاهل شهادات SSL / TLS منتهية الصلاحية أو غير الصالحة وتحذيرات المتصفح الأخرى. يتم تعيين قيمة HSTS لكل متصفح يزور موقع الويب. لم يتم ضبطه لكل جهاز.

يوفر رأس HSTS خيارًا لتضمين أي مجالات فرعية - يمكنك استخدام التوجيه "includeSubDomains" لاعتماد نفس مستوى الأمان من المجال الجذر. هذا يعني أن أي تطوير محلي مع المجال (أو المجالات الفرعية) لن يكون متاحًا بعد الآن من خلال HTTP لأن المتصفح سيسمح فقط بحركة مرور HTTPS.

على سبيل المثال ، إذا كان لديك رؤوس HSTS على example.com مع التوجيه الضروري "includeSubdomains " ، فلن تتمكن من الوصول إلى المجالات الفرعية لـ example.com عبر اتصالات غير آمنة بمجرد زيارة example.com. لذلك ، كن حذرًا إذا اخترت استخدام "includeSubdomains" ، فقد يكون لها آثار على نطاقاتك الأخرى.

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

صيغة هذا الرأس هي:

 # بدون توجيه includeSubDomains
<IfModule mod_headers.c>
مجموعة الرأس Strict-Transport-Security: “max-age = 63072000؛”
</IfModule>
# مع التوجيه includeSubDomains
<IfModule mod_headers.c>
مجموعة الرأس Strict-Transport-Security "max-age = 31536000؛ includeSubDomains؛ preload" 
</IfModule>

يحدد التوجيه max-age = <expire-time> الوقت (بالثواني) الذي يجب أن يتذكر فيه المتصفح أنه لا يمكن الوصول إلى الموقع إلا باستخدام HTTPS. على سبيل المثال ، في المثال أعلاه ، تم تعيين الحد الأقصى للعمر على عامين. إذا اخترت أن يكون لديك Servebolt CDN أو Accelerated Domains من Servbolt ، فسيكون لديك تلقائيًا عام واحد من HSTS.

4. عنوان سياسة المُحيل

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

يمكن أن تحتوي على عدة قيم - إليك ملخص سريع:

• لا يوجد مُحيل: لن يتم إرسال عنوان المُحيل أبدًا تحت أي ظرف من الظروف.
• لا يوجد مُحيل عند الرجوع إلى إصدار أقدم: لن يتم إرسال رأس المُحيل عند التنقل من موقع HTTPS إلى موقع HTTP.
• الأصل: سيتضمن عنوان المرجع فقط أصل (المخطط والمضيف والمنفذ) لصفحة الإحالة.
• Origin-when-cross-origin: سيتضمن رأس المرجع عنوان URL الكامل لصفحة الإحالة عند التنقل بين الصفحات داخل نفس الأصل والأصل فقط عند الانتقال إلى أصل مختلف.
• أصل صارم: سيتضمن عنوان المرجع فقط أصل صفحة الإحالة ولن يتم إرساله لطلبات عبر الأصل.
• Strict-origin-when-cross-origin: سيتضمن رأس المرجع أصل الصفحة المُحيلة ولن يتم إرساله لطلبات عبر الأصل باستثناء أصول نفس الموقع. نوصي باستخدام هذا الإعداد لأنه يحتفظ بفائدة الرأس مع تقليل مخاطر تسرب البيانات.
• عنوان url غير آمن: سيرسل رأس المرجع الأصل والمسار وسلسلة الاستعلام عند تنفيذ أي طلب ، بغض النظر عن الأمان.

لإجراء مناقشة متعمقة حول عنوان سياسة المُحيل ، اقرأ مقالة Google web.dev حول أفضل الممارسات لسياسة المُحيل .

5. رأس X-Content-Type-Options

يتم إرسال رأس X-Content-Type-Options بواسطة الخادم في استجابة HTTP للإشارة إلى المتصفحات حول أنواع MIME. الغرض من هذا العنوان هو منع المتصفحات من تفسير الملفات كنوع MIME مختلف عن النوع المحدد في الرأس.

يمكن أن يكون لهذا العنوان قيمة واحدة "nosniff". بناء الجملة كما يلي:

 خيارات نوع المحتوى X: nosniff

إنه فعال للغاية ضد هجمات ارتباك MIME - استخدام رأس الأمان هذا يمكن أن يمنع المتصفح من تفسير الملفات بطرق غير متوقعة قد تؤدي إلى ثغرات أمنية. على سبيل المثال ، إذا قام المهاجم بتحميل ملف بامتداد jpg ولكنه لا يحتوي على محتوى لأنه في الواقع نص برمجي ، فإن تعيين رأس X-Content-Type-Options على "nosniff" لن يسمح للمتصفح بتنفيذ البرنامج النصي ، وبالتالي حماية المستخدمين من الانتهاكات المحتملة.

6. عنوان سياسة أمان المحتوى(CSP)

Content-Security-Policy هو عنوان أمان يستخدم لتحديد أصل المحتوى ويوفر آلية للمحتوى المسموح بتحميله وتنفيذه في موقع ويب أو تطبيق ويب. من خلال تحديد مجموعة من السياسات ، يمكن لهذا العنوان تقييد أنواع المحتوى المسموح بها على صفحة الويب والتخفيف من أنواع التهديدات الأمنية المختلفة. إنها طبقة أمان إضافية ضد هجمات البرمجة النصية عبر المواقع (XSS) وهجمات حقن البيانات التي تُستخدم في جرائم مثل سرقة البيانات وتشويه الموقع وتوزيع البرامج الضارة.

بالإضافة إلى التحكم في أنواع الموارد التي يمكن تحميلها ، يوفر رأس Content-Security-Policy أيضًا طريقة لإرشاد المستعرض حول كيفية التعامل مع أي انتهاك للسياسات المحددة في العنوان. على سبيل المثال ، قد تحدد السياسة أنه في حالة انتهاك أحد الموارد للسياسة ، يجب على المتصفح نشر تحذير أو حظر تحميل المورد.

يجب تكوين الخادم لإرجاع رأس سياسة أمان المحتوى حتى تعمل السياسات. يمكنك استخدام رأس CSP HTTP لتحديد سياستك مثل هذا:

 سياسة أمن المحتوى: السياسة

هذه السياسة عبارة عن سلسلة تحتوي على توجيهات السياسة التي تصف سياسة أمان المحتوى الخاصة بك. على سبيل المثال ، يمكنك إضافة الأسطر التالية إلى ملف htaccess الخاص بك لتنفيذ CSP.

 <IfModule mod_headers.c>
تعيين الرأس Content-Security-Policy "default-src https:" unsafe-Eval "غير آمن-مضمّن" self "؛ كائن src" self "؛ font-src https: data:" self "http: fonts.googleapis. com theme.googleusercontent.com؛ connect-src https: wss: 'self'؛ img-src https: data: 'self' http: * .gravatar.com؛ worker-src blob: https: 'self' nonafe-inline "غير آمنة-EVAL" ؛ media-src https: blob: "self" ؛ style-src https: "unsafe-Eval"
</IfModule>

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

• default-src - يعيّن هذا التوجيه السياسة الافتراضية لجميع أنواع الموارد ما لم يتم تجاوزها بواسطة توجيهات أخرى.في هذه الحالة ، يسمح بتحميل الموارد من نفس المصدر ("الذات") ، وكذلك من مصادر HTTPS ومن البرامج النصية التي تستخدم "التقييم غير الآمن" أو "غير الآمن المضمّن".
• object-src - يقيد هذا التوجيه أنواع الكائنات التي يمكن تضمينها في الصفحة ، مثل تطبيقات Flash أو Java.هنا ، يسمح بتحميل الكائنات فقط من نفس الأصل ("الذات").
• font-src - يقيد هذا التوجيه المصادر التي يمكن تحميل الخطوط منها.هنا ، يسمح بتحميل الخطوط من مصادر HTTPS ، ونظام URI للبيانات ، ومن نفس الأصل ("ذاتي") أو من مصادر HTTP من خطوط Google ومحتوى مستخدم Google.
• connect-src - يقيد هذا التوجيه المصادر التي يمكن استخدامها لطلبات الشبكة ، مثل طلبات AJAX أو WebSockets.هنا ، يسمح بإجراء الاتصالات فقط عبر HTTPS أو WebSockets ومن نفس الأصل ("الذات").
• img-src - يقيد هذا التوجيه المصادر التي يمكن من خلالها تحميل الصور.هنا ، يسمح بتحميل الصور من مصادر HTTPS ، ونظام URI للبيانات ، ومن نفس الأصل ("الذات") أو من مصادر HTTP من Gravatar.
• worker-src - يقيد هذا التوجيه المصادر التي يمكن من خلالها تحميل العاملين على الويب.هنا ، يسمح للعمال بالتحميل فقط من مخطط blob URI ومصادر HTTPS ومن البرامج النصية التي تستخدم "تقييم غير آمن" أو "غير آمن مضمّن".
• media-src - يقيد هذا التوجيه المصادر التي يمكن من خلالها تحميل موارد الوسائط ، مثل الصوت أو الفيديو.هنا ، يسمح بتحميل الوسائط فقط من مصادر HTTPS ، مخطط blob URI ومن نفس الأصل ("الذات").
• style-src - يقيد هذا التوجيه المصادر التي يمكن من خلالها تحميل أوراق الأنماط.هنا ، يسمح بتحميل الأنماط من مصادر HTTPS ومن البرامج النصية التي تستخدم "تقييم غير آمن" أو "غير آمن مضمّن" ، وكذلك من نفس الأصل ("ذاتي") ومن مصادر HTTP من خطوط Google.

عند استخدام رأس CSP مع مثيل WordPress الخاص بك ، من المهم ملاحظة أنالتطبيق غير الصحيح لرؤوس CSP سيؤدي إلى كسر لوحة تحكم مسؤول WordPress لأن بعض المكونات الإضافية والخدمات قد تعتمد على JavaScript تابع لجهة خارجية.

لإصلاح ذلك ، ستحتاج إلى إضافة كل قاعدة أمان إلى ملف الرؤوس يدويًا. هناك طريقة بديلة ، ولكنها أقل أمانًا ، وهي تعطيل رأس CSP في لوحة تحكم المسؤول. على سبيل المثال ، إليك ما نفعله على servebolt.com :

 مجموعة رأس X-Frame-Options SAMEORIGIN
مجموعة رأس سياسة المُحيل صارمة الأصل عند عبور الأصل
مجموعة الرأس X-XSS-Protection "1 ؛ mode = block"
<إذا كان "٪ {REQUEST_URI}! ~ / wp-admin /">
# أضف رأس فقط إذا لم يكن شاشة المسؤول
يعيّن الرأس دائمًا Content-Security-Policy "default-src 'self" "unsafe-inline" ؛ script-src "self" "unsafe-inline" "unsafe-Eval" * .intercomcdn.com cdn.firstpromoter.com servebolt.containers .piwik.pro * .intercom.io cdn.getreplybox.com platform.twitter.com v0.wordpress.com cdn.jsdelivr.net servebolt.piwik.pro؛ media-src 'self' * .intercomcdn.com data:؛ img -src 'self' 'unsafe-inline' * .intercom.io * .intercomcdn.com * .intercomassets.com data: raskesider.raskesider.no * .servebolt.com secure.gravatar.com servebolt.piwik.pro؛ connect- src 'self' ws: nexus-websocket-a.intercom.io * .piwik.pro servebolt.piwik.pro * .intercom.io؛ font-src 'self' * .intercomcdn.com data:؛ frame-src 'self "app.getreplybox.com platform.twitter.com player.vimeo.com wordpress.org www.youtube.com caniuse.bitsofco.de video.wordpress.com * .intercom.io ؛ إطار أجداد" الذات "* .servebolt. com؛ manifest-src 'self'؛ "
</If>

أثناء فرض CSP على موقعك ، يجب أن تلاحظ أنه قد يفسد بيئة التطوير الخاصة بك إذا كنت لا تستخدم HTTPS. إذا لم تكن متأكدًا من كيفية إنشاء سياسة لموقعك ، فيجب عليك استخدام أداة رسومية مثل ValidBot - CSP Wizard أو Report URI: CSP generator .

7. عنوان سياسة الأذونات

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

تسمح سياسة الأذونات للخادم بتعيين ما إذا كان يمكن استخدام ميزة في مستند معين. يستخدمallowlists - قائمة الأصول التي تأخذ قيمًا محددة مسبقًا.تتكون قيمة عنوان سياسة الأذونات من قائمة مفصولة بفواصل بأسماء التوجيهات وقيمها التي تصف الأذونات المختلفة التي يتطلبها موقع الويب.

الصيغة العامة لرأس سياسة الأذونات هي:

 سياسة الأذونات: <directive> = <allowlist>

على سبيل المثال ، إذا احتجنا إلى حظر كل الوصول إلى الموقع الجغرافي ، فسنقوم بذلك:

 سياسة الأذونات: تحديد الموقع الجغرافي = ()

هنا ، يشير الرمز () إلى قائمة السماح الفارغة. للسماح بالوصول إلى مجموعة فرعية من الأصول ، يمكننا القيام بذلك:

 <IfModule mod_headers.c>
دائمًا ما يضبط الرأس أذونات السياسة "الموقع الجغرافي = (ذاتي 'https://abc.example.com' 'https://pqr.example.com') ، midi = () ، sync-xhr = () ، مقياس التسارع = ( ) ، الجيروسكوب = () ، مقياس المغناطيسية = () ، الكاميرا = () ، الميكروفون = () ، ملء الشاشة = (النفس) "
</IfModule>

لنأخذ مثالاً آخر. تقيد قيمة الرأس التالية موقع الويب فقط لتنفيذ البرامج النصية إذا تم تقديمها من نفس أصل المستند الرئيسي:

 سياسة الأذونات: script-src 'self'

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

إضافة رؤوس أمان HTTP باستخدام ملف .htaccess

الطريقة التي نوصي بها بإضافة رؤوس أمان HTTP هي تحرير ملف .htaccessمباشرةً. هذا هو ملف تكوين الخادم الأكثر استخدامًا بواسطة خوادم الويب Apache. بتحرير هذا الملف ، فإنك تضمن أن رؤوس أمان HTTP في WordPress قد تم تكوينها على مستوى الخادم.

ستحتاج إلى الوصول إلى ملفhtaccessالخاص بموقعك لاستخدام هذه الطريقة. يمكن الوصول إليه على خوادم Apache باستخدام عميل FTP.قبل إجراء أي تغييرات ، يوصى بشدة بعمل نسخة احتياطية من ملف htaccessالحالي.

أولاً ، ما عليك سوى تسجيل الدخول إلى موقعك باستخدام عميل FTP أو أداة مدير الملفات في لوحة تحكم الاستضافة. في المجلد الجذر لموقع الويب الخاص بك ، حدد موقع ملف.htaccessوانقر بزر الماوس الأيمن على خيار "تحرير". سيؤدي هذا إلى فتح الملف باستخدام محرر نصوص. لإضافة رؤوس أمان HTTPS إلى موقعك ، يمكنك إضافة الشفرة ذات الصلة في الجزء السفلي من ملف htaccess.

يمكن استخدام نموذج التعليمات البرمجية التالي كنقطة بداية.يقوم بتعيين رؤوس أمان HTTP الأكثر استخدامًا بالإعدادات الموصى بها.

 <IfModule mod_headers.c>
مجموعة الرأس Strict-Transport-Security "max-age = 31536000 ؛ includeSubDomains ؛ تحميل مسبق" env = HTTPS
مجموعة الرأس X-XSS-Protection "1 ؛ mode = block"
مجموعة رأس X-Content-Type-Options "nosniff"
مجموعة رأس X-Frame-Options DENY
مجموعة الرأس "سياسة المُحيل" "لا يوجد مُحيل عند الرجوع إلى إصدار أقدم"
تعيين الرأس Content-Security-Policy "default-src https:" unsafe-Eval "غير آمن-مضمّن" self "؛ كائن src" self "؛ font-src https: data:" self "http: fonts.googleapis. com theme.googleusercontent.com؛ connect-src https: wss: 'self'؛ img-src https: data: 'self' http: * .gravatar.com؛ worker-src blob: https: 'self' nonafe-inline "غير آمنة-EVAL" ؛ media-src https: blob: "self" ؛ style-src https: "unsafe-Eval"
دائمًا ما يضبط الرأس أذونات السياسة "الموقع الجغرافي = (ذاتي 'https://abc.example.com' 'https://pqr.example.com') ، midi = () ، sync-xhr = () ، مقياس التسارع = ( ) ، الجيروسكوب = () ، مقياس المغناطيسية = () ، الكاميرا = () ، الميكروفون = () ، ملء الشاشة = (النفس) "
</IfModule>

بمجرد إضافة التكوين أعلاه إلى ملف htaccess الخاص بك ، سيتم تطبيق الرؤوس ذات الصلة على جميع طلبات الويب.

يمكنك التحقق من استخدام الرؤوس من خلال فتح علامة التبويب "الشبكة" في Chrome DevTools وفحص رؤوس الاستجابة لطلبك.

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

إضافة رؤوس أمان HTTP في WordPress باستخدام شبكة توزيع المحتوى (CDN)

شبكة توصيل المحتوى (CDN) هي مجموعة من الخوادم الموزعة جغرافيًا والتي توفر محتوى الإنترنت المخزن مؤقتًا من موقع الشبكة الأقرب إلى المستخدم لتحسين أداء الويب. تمكّنك شبكات CDN الشائعة مثلCloudflare أيضًا من إضافة رؤوس HTTP إلى موقع الويب الخاص بك.

لنأخذ Cloudflare كمثال ونرى كيف يمكننا إضافة رؤوس HTTP باستخدام CDN. تقدم Cloudflare جدار حماية مجانيًا أوليًا لموقع الويب جنبًا إلى جنب مع خدمة CDN ، ولكن ميزات الأمان الأكثر تقدمًا مقفلة خلف جدار حماية.

يعد إعداد Cloudflare على موقع WordPress الخاص بك أمرًا سهلاً للغاية. يمكنك التسجيل يدويًا على موقع Cloudflare على الويب واتباع الخطوات التي تظهر على الشاشة لتمكينه. بمجرد تنشيط Cloudflare على موقع الويب الخاص بك ، توجه إلى صفحة SSL / TLS في لوحة معلومات حساب Cloudflare الخاص بك.

ستحتاج بعد ذلك إلى التبديل إلى علامة التبويب "شهادات الحافة" وتحديد موقع قسم HTTP Strict Transport Security (HSTS) ، والنقر فوق الخيار "Enable HSTS". بعد تشغيل زر "تمكين HSTS" ، ستظهر نافذة منبثقة تحتوي على إرشادات لمساعدتك في تمكين هذه الميزة على موقعك. انقر فوق الزر "التالي" لمتابعة العملية ، وسترى خيار إضافة رؤوس أمان HTTP.

من هنا ، يمكنك تمكين HSTS على موقعك واختيار تطبيق HSTS أيضًا على النطاقات الفرعية التي تستخدم HTTPS. سيؤدي استخدام هذه الطريقة إلى توفير حماية أساسية لموقعك باستخدام رؤوس أمان HTTP ، ولكن الجانب السلبي هو أن Cloudflare لا يتيح لك إضافة خيارات إطار X حاليًا.

تجدر الإشارة إلى أنه بالنسبة إلى servebolt.com وأي مجالات أخرى داخل Cloudflare ، يتم تمكين HSTS افتراضيًا.

إضافة رؤوس أمان HTTP باستخدام مكون WordPress الإضافي

الطريقة الثالثة لإضافة وتكوين رؤوس HTTP هي استخدام مكون إضافي. على الرغم من أن هذه إحدى أسهل الطرق لإضافة رؤوس HTTP Security إلى موقع WordPress الخاص بك ، إلا أنها عادة ما تكون أقل فاعلية من تكوين الرؤوس يدويًا.

ربما تكون قد قرأت بالفعل في مكان آخر أن العديد من المكونات الإضافية للأمان تتضمن خيار إضافة رؤوس أمان. ومع ذلك ، نوصي بعدم استخدام مكون إضافي للأمان. اقرأ مقالتنا حول مكونات أمان WordPress لفهم سبب استخدام هذه المكونات وما هي المخاوف.

سيتيح لك هذا القسم تمكين أو تعطيل الرؤوس المختلفة وتعيين معلمات مختلفة لها. ستختلف الرؤوس الدقيقة التي يمكنك تمكينها اعتمادًا على المكون الإضافي الذي تختاره ، ولكن تتم تغطية العناوين الشائعة مثل X-XSS-Protection و X-Content-Type-Options و X-Frame-Options و Strict-Transport-Security بواسطة معظم الإضافات.

كيفية التحقق من رؤوس أمان HTTP على موقع الويب الخاص بك

بعد إضافة رؤوس أمان HTTP على موقع WordPress الخاص بك ، تحتاج إلى التأكد من تهيئتها بشكل صحيح ومن عملها كما هو متوقع. يمكنك استخدام واحدة من العديد من الأدوات المجانية المتاحة على الإنترنت لإجراء اختبار. نوصي باستخدام إما Security Headers أو SSL Labs ، وكلاهما يوفر لك طريقة سهلة لاختبار التكوين الخاص بك والتحقق من أن جميع رؤوس الأمان تعمل بشكل صحيح.

ستعمل هذه الأدوات على تقييم رؤوس أمان موقع الويب الخاص بك وتزويدك بتقرير مفصل. كما تخبرك أيضًا برؤوس أمان HTTP التي يرسلها موقع الويب الخاص بك وأيها لا يتم إرسالها. سيتم بعد ذلك منح موقعك درجة من A + إلى F ، جنبًا إلى جنب مع شرح لكيفية تحديد هذه الدرجة.

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

وكما قد تتوقع عند اختبار موقع الويب الخاص بنا - فإنه يحصل على درجة A +.

خاتمة

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

1. اختبار الثغرات الأمنية : من المهم اختبار موقعك بحثًا عن الثغرات الأمنية الشائعة مثل البرمجة النصية عبر المواقع (CSS) و Cross-site-request-Forgery (CSRF).لهذا الغرض ، يمكنك استخدام أدوات مثل OWASP ZAP و Burp Suite .
2. مراقبة التغييرات : تحتاج إلى مراقبة الرؤوس بانتظام بحثًا عن أي تغييرات غير متوقعة ، حيث يشير هذا عادةً إلى وجود محاولات لاستغلال ثغرة أمنية.
3. تحديث الرؤوس : مع ظهور تهديدات جديدة ، من المهم أن تظل على اطلاع دائم بأحدث ممارسات الأمان وتحديث الرؤوس وفقًا لذلك.

هل أنت مهتم بالاستضافة المدارة الأسرع تجريبياً؟

جرب أسلوبنا في استضافة WordPress - البدء مجاني ، وتشمل الفوائد:

• قابلية التوسع: في اختبارات عبء عمل المستخدم الحقيقي ، قدم Servebolt متوسط ​​أوقات استجابة 65 مللي ثانية ، وأوقات استجابة أسرع 4.9 مرة من ثاني أفضل.
• أسرع أوقات تحميل عالمية: يضعنا متوسط ​​أوقات تحميل الصفحة البالغة 1.26 ثانية على رأس قائمة نتائج WebPageTest العالمية.
• أسرع سرعة للحوسبة: توفر خوادم Servebolt سرعات قاعدة بيانات لم يسمع بها من قبل ، وتعالج 2.44 مرة استعلامات في الثانية أكثر من المتوسط ​​وتشغيل PHP 2.6 مرة أسرع من ثاني أفضل!
• أمان مثالي ووقت تشغيل: مع وقت تشغيل بنسبة 100٪ على جميع الشاشات وتصنيف A + على تطبيق SSL الخاص بنا ، يمكنك التأكد من أن موقعك متصل بالإنترنت وآمن.

باختصار ، بالسماح لنا بإزالة الاستضافة من لوحة الخاص بك - ستجعل تحسين أمان موقعك وسرعته وأدائه أسهل. اشترك في Servebolt لوضعنا في الاختبار.