HSTS: HTTP Strict Transport Security لتحسين محركات البحث

الخلاصة — HSTS هو تعليمة صغيرة يرسلها خادمك إلى المتصفحات تقول “استخدم دائمًا HTTPS لموقعي — أبدًا HTTP العادي.” يسد ثغرة أمنية صغيرة يتركها تحويل HTTP→HTTPS العادي مفتوحة، ولا يضر بتحسين محركات البحث. لكنه صارم عن قصد: بمجرد تفعيله، شهادة معطوبة تعطل موقعك دون أي طريقة للزوار لتجاوز التحذير. فعّله فقط عندما يكون إعداد HTTPS لديك متينًا حقًا.

ما هو HSTS

أنت تعلم بالفعل أنه يجب أن تكون على HTTPS — النسخة المشفرة ذات القفل لموقعك. الطريقة العادية لفرض ذلك هي إعادة التوجيه: عندما يكتب شخص http://yoursite.com، يرسل له خادمك إعادة توجيه 301 إلى https://yoursite.com. هذا يعمل، لكن هناك فجوة صغيرة. ذلك الطلب الأول جدًا — الطلب قبل أن تعمل إعادة التوجيه — لا يزال يخرج عبر HTTP غير آمن. يمكن لمهاجم على نفس شبكة Wi-Fi أن ينقض في تلك النافذة.

HSTS — HTTP Strict Transport Security — يسد تلك الفجوة. إنها تعليمة قصيرة (أو “ترويسة”) يضيفها خادمك إلى استجاباته — ولكن فقط تلك التي تُقدَّم عبر اتصال آمن حقًا؛ الترويسة نفسها المرسلة عبر HTTP العادي تُتجاهل، لأن المهاجم قد يحقنها أو يزيلها — تخبر ذلك المتصفح الواحد: خلال الأشهر القليلة القادمة، لا تحاول حتى استخدام HTTP لهذا الموقع — اذهب مباشرة إلى HTTPS. إنها سياسة يتعلمها كل متصفح ويخزنها لنفسه، وليست شيئًا يغير خادمك. بمجرد أن يراها المتصفح، يرقّي روابط http:// إلى https:// من تلقاء نفسه، قبل أن يغادر أي شيء الجهاز. Evidence for this claim After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. Scope: MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. Confidence: high · Verified: 2026-07-14 MDN: Strict-Transport-Security header

هل يساعد HSTS أو يضر بتحسين محركات البحث؟

لا شيء من ذلك، بشكل مباشر. HSTS هو ميزة أمان وثقة، وليس أداة ترتيب. لن يرفعك في النتائج — لكن إذا تم بشكل صحيح فلن يضرك أيضًا. الشيء الوحيد الذي يجب فهمه هو أن HSTS ليس بديلاً عن عمليات إعادة التوجيه الخاصة بك. لا تزال تحتاج إلى عمليات إعادة التوجيه 301 الحقيقية من جانب الخادم من HTTP إلى HTTPS، لأن هذا هو ما تراه وتستخدمه Google وBing فعليًا. يعمل HSTS داخل المتصفح للزوار البشريين الحقيقيين؛ لا تعتمد عليه برامج الزحف. احتفظ بكليهما.

التحذير الكبير الوحيد

HSTS غير متسامح عمدًا. بمجرد أن “يتعلم” المتصفح أن موقعك HTTPS فقط، سيرفض تحميل الموقع تمامًا إذا انتهت صلاحية شهادتك أو حدث خطأ في إعدادها — دون أي زر “متابعة على أي حال”. هذا هو الهدف كله (يمنع المهاجمين من خداع الناس للانتقال إلى نسخة HTTP مزيفة)، لكنه يعني أن الشهادة المنتهية تتحول من “تحذير مزعج” إلى “الموقع معطل لأي شخص زاره من قبل.”

هناك أيضًا نسخة فائقة تسمى preload تدمج نطاقك في المتصفح نفسه. إنها رائعة، لكن إزالة النطاق من قائمة preload لاحقًا بطيئة ومؤلمة — فكر في أشهر. لذا فإن preload باب باتجاه واحد: لا تدخل منه إلا عندما تكون متأكدًا. Evidence for this claim HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. Scope: The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. Confidence: high · Verified: 2026-07-17 Chromium: HSTS Preload List Submission

تريد صيغة الترويسة، وإعادة التوجيه الداخلية للمتصفح فقط التي لا تراها برامج الزحف، ومتطلبات preload، وسيناريوهات الإغلاق الحقيقية؟ انتقل إلى علامة التبويب متقدم.

TL;DR — HSTS هو ترويسة الاستجابة Strict-Transport-Security، ولا يتم تكريمها إلا عندما يستقبلها المتصفح عبر اتصال آمن، ويتم تخزينها لكل عميل كسياسة مستقبلية لذلك المضيف. إنها تسد “مشكلة الطلب الأول” التي يتركها 301 وحده مفتوحة: طلب HTTP الأولي من زائر جديد غير آمن حتى يتم تشغيل إعادة التوجيه، وهذه هي النافذة التي يريدها المهاجم الذي يجرد SSL. ثلاثة توجيهات: max-age (مطلوب، بالثواني)، includeSubDomains، preload. عندما يفرض المتصفح HSTS، فإنه يعيد كتابة URI إلى HTTPS داخليًا، قبل أي طلب يصل إلى الخادم — لا يفرض RFC 6797 رمز حالة محددًا لذلك إعادة الكتابة، على الرغم من أن الأدوات غالبًا ما تعرضها كـ 307 — لذا فإن 301 من جانب الخادم لا تزال إلزامية لمحركات البحث وحقوق الارتباط؛ HSTS فوقها، وليس بدلاً منها. Preload يدمج نطاقك في المتصفح عبر hstspreload.org (يتطلب max-age ≥ 31536000، includeSubDomains، وpreload) وهو قريب من اللارجعة — الإزالة هي إرسال منفصل يستغرق شهورًا للوصول إلى المستخدمين. وHSTS مصمم للفشل الصارم عند أي خطأ في الشهادة، لذا قم بتمكينه فقط عندما يكون HTTPS قويًا عبر كل نطاق فرعي.

يقدم مركز HTTPS HSTS كحماية على مستوى المتصفح تقع فوق 301 الخاص بك. هذه الصفحة هي الغوص العميق: بناء جملة الترويسة الدقيق، إعادة التوجيه الداخلية التي تربك خبراء SEO، شبه اللارجعة لقائمة preload، والطرق الواقعية التي يقفل بها HSTS الأشخاص خارجًا.

المشكلة التي يحلها HSTS فعليًا: الطلب الأول

تخيل موقعًا تم ترحيله بشكل صحيح. كل http:// URL يعيد توجيه 301 إلى توأمه https://، الشهادة صالحة، والكنونيكالات تشير إلى HTTPS. يبدو محكمًا. ليس كذلك تمامًا.

عندما يكتب زائر جديد تمامًا yoursite.com (بدون مخطط) أو ينقر على رابط قديم http://yoursite.com، يخرج طلب المتصفح الأول عبر HTTP عادي. يجيب خادمك بـ 301، وكل طلب بعد ذلك آمن. لكن تلك الجولة الأولية الواحدة حدثت في العلن — وهذه بالضبط هي النافذة التي يريدها مهاجم تجريد SSL على نفس الشبكة. يعترضون طلب HTTP، ويبقون الضحية على HTTP بينما يمررون HTTPS إلى خادمك، ويقرؤون أو يعيدون كتابة كل شيء.

يزيل HSTS تلك النافذة لأي شخص زار من قبل. web.dev مباشر حول الآلية: “use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” (ترجمة) «استخدم Strict Transport Security لإخبار العملاء بأنه يجب عليهم دائمًا الاتصال بخادمك باستخدام HTTPS، حتى عند اتباع مرجع http://. هذا يهزم هجمات مثل SSL Stripping، ويتجنب تكلفة الرحلة ذهابًا وإيابًا لإعادة توجيه 301.» (web.dev). تلك الجملة الأخيرة مهمة للأداء أيضًا: متصفح عائد يتخطى رحلة HTTP→HTTPS بالكامل. Evidence for this claim After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. Scope: MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. Confidence: high · Verified: 2026-07-14 MDN: Strict-Transport-Security header

شرطان حدوديان يستحقان الدقة. أولاً، HSTS هو سياسة مخزنة لكل عميل — تعيش في حالة ذلك المتصفح الواحد لهذا المضيف، المستفادة من ترويسة تم تسليمها عبر اتصال آمن؛ نفس الترويسة المرسلة على استجابة HTTP يتم تجاهلها تمامًا (المهاجم الذي يمكنه حقن أو تجريد الترويسات على HTTP عادي يمكنه بخلاف ذلك تحييدها)، والعميل الذي لم يستقبلها أبدًا — تثبيت جديد، متصفح مختلف، زاحف — ليس لديه سياسة لفرضها. ثانيًا، إعادة الكتابة واعية بالمخطط والمنفذ: طلب منفذ 80 ضمني يصبح طلب منفذ 443 ضمني، ولكن إذا كان URI الأصلي يسمي منفذًا صريحًا غير افتراضي، يحتفظ المتصفح بنفس رقم المنفذ ويتصل به ببساطة عبر HTTPS بدلاً من ذلك.

بناء جملة الترويسة

HSTS هو ترويسة استجابة واحدة تحتوي على ما يصل إلى ثلاثة توجيهات. وفقًا MDN، الأشكال هي:

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

• max-age=<seconds> — مطلوب. “الوقت، بالثواني، الذي يجب أن يتذكره المتصفح أن المضيف لا يمكن الوصول إليه إلا عبر HTTPS” (MDN). 31536000 هي سنة واحدة؛ 63072000 هي سنتان. الساعة تُعاد ضبطها عند كل استجابة تحمل الترويسة، لذا فإن الموقع النشط يجدد سياسته باستمرار. هذه حالة نسبية خاصة بكل عميل: إزالة الترويسة ببساطة لا تمسحها فورًا — المتصفح الذي تعلم السياسة بالفعل يستمر في تطبيقها حتى تنتهي مدة max-age المخزنة لديه. لإيقاف تشغيل HSTS للعملاء الذين تعلموها بالفعل، يجب عليك تقديم max-age=0 بنشاط عبر استجابة آمنة؛ عندها ينسى المتصفح السياسة في زيارته الآمنة التالية. (max-age=0 تمسح سياسة متعلمة فقط — لا تزيل نطاقًا من قائمة التحميل المسبق المنفصلة.)
• includeSubDomains — اختياري. “إذا تم تحديد هذا التوجيه، تنطبق سياسة HSTS على جميع النطاقات الفرعية لنطاق المضيف أيضًا” (MDN). قوي وخطير بنفس القدر — انظر سيناريوهات الإغلاق أدناه.
• preload — اختياري. علامة تشير إلى نيتك في أن تكون ضمن قائمة التحميل المسبق للمتصفح. لا تفعل شيئًا بمفردها؛ إنها شرط أساسي للتقديم إلى hstspreload.org. Evidence for this claim HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. Scope: The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. Confidence: high · Verified: 2026-07-17 Chromium: HSTS Preload List Submission

السلوك، مرة أخرى من MDN: “قبل تحميل عنوان http URL، يتحقق المتصفح من اسم النطاق مقابل قائمة مضيفي HSTS. إذا كان اسم النطاق مطابقًا غير حساس لحالة الأحرف لمضيف HSTS أو كان نطاقًا فرعيًا لمضيف حدد includeSubDomains، فإن المتصفح يستبدل مخطط URL بـ https.”

الترقية الداخلية التي لا يراها الزاحفون أبدًا (هذا هو جوهر SEO)

إليك أكثر شيء يساء فهمه حول HSTS، والسبب الذي يجعله لا يمكن أن يحل محل عمليات إعادة التوجيه الخاصة بك.

عندما يقوم المتصفح بترقية طلب http:// تحت HSTS، فإنه يعيد كتابة URI إلى HTTPS داخليًا، قبل إجراء أي طلب شبكة — يتطلب RFC 6797 استبدال المخطط نفسه ولكنه لا يفرض رمز حالة معينًا له (RFC 6797 §8.3)، لذا قد يمثل متصفح أو أداة زحف معينة تلك الخطوة الداخلية كما يحلو لها — يعرضها الكثيرون كـ 307 داخلي، لكن هذا خاص بالعميل/الأداة، وليس ضمانًا بروتوكوليًا. ما يهم لتحسين محركات البحث أبسط ويظل صحيحًا بغض النظر عن التسمية: لا يتم الاتصال بالخادم لإصدار HTTP، لذا لا يراه أي زاحف أبدًا. لا يحمل Googlebot و Bingbot سياسة HSTS متعلمة بالطريقة التي يحملها Chrome البشري العائد — يصلون إلى خادمك من جديد، وما يحتاجون إلى رؤيته هناك هو 301 حقيقي من جانب الخادم. Evidence for this claim RFC 6797 requires the user agent to rewrite a known-HSTS-host HTTP URI to HTTPS internally, but does not mandate any specific redirect status code for that internal rewrite; how a given browser or crawling tool represents that step (e.g., as an internal 307) is a client/tool implementation detail, not a protocol requirement. Scope: RFC 6797 Section 8.3 ("URI Loading and Port Mapping") specifies the UA MUST replace the URI scheme with https; it does not prescribe an HTTP status code for that internal substitution, since no HTTP exchange occurs for it. Section 7.2's suggestion of status code 301 addresses ordinary server-side redirect behavior, not this internal client-side rewrite. Confidence: high · Verified: 2026-07-17 RFC 6797 §8.3 — URI Loading and Port Mapping

لذا فإن القاعدة واضحة: HSTS لا يحل محل عمليات إعادة التوجيه 301 من جانب الخادم. الـ 301 هو ما تستخدمه محركات البحث لفهم انتقال البروتوكول وتوحيد الإشارات (“301 and other permanent redirects don’t cause a loss in PageRank” (ترجمة) «عمليات 301 وغيرها من عمليات إعادة التوجيه الدائمة لا تسبب فقدان PageRank» المصدر، وفقًا لجوجل). الترقية الداخلية للمتصفح فقط هي طبقة تجربة المستخدم والأمان فوق ذلك. تحتاج إلى كليهما، يقومان بمهام مختلفة:

• 301 (من جانب الخادم): للزاحفين والفهرسة وحقوق الارتباط.
• ترقية داخلية بنمط 307 (من جانب المتصفح، من HSTS): للبشر العائدين وحماية من تجريد SSL — تمثيل الحالة الدقيق يختلف حسب العميل/الأداة.

أي دليل يخبرك أن HSTS “يتعامل مع إعادة التوجيه بحيث يمكنك التخلي عن 301 الخاص بك” هو خطأ بطريقة ستكلفك بهدوء.

HSTS preload: النسخة شبه الدائمة

max-age يحمي الزوار العائدين، لكنه يعاني من مشكلة التمهيد: الزائر لأول مرة الذي لم يستلم رأسك بعد لا يزال معرضًا للخطر في ذلك الطلب الأولي. Preload يحل هذه المشكلة عن طريق ترميز نطاقك في مصدر المتصفح نفسه، بحيث يعرف المتصفح أنك HTTPS فقط قبل أن يتصل بك أبدًا.

يمكنك الاشتراك في hstspreload.org. المتطلبات دقيقة:

1. “Serve a valid certificate.” (ترجمة) «قدّم شهادة صالحة.»
2. “Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.” (ترجمة) «أعد التوجيه من HTTP إلى HTTPS على نفس المضيف، إذا كنت تستمع على المنفذ 80.»
3. “Serve all subdomains over HTTPS” (ترجمة) «قدّم جميع النطاقات الفرعية عبر HTTPS» — بما في ذلك على وجه الخصوص النطاق الفرعي www إذا كان سجل DNS موجودًا.
4. على استجابة HTTPS للنطاق الأساسي، رأس HSTS حيث “the max-age must be at least 31536000 seconds (1 year),” (ترجمة) «يجب أن يكون max-age على الأقل 31536000 ثانية (سنة واحدة)،» “the includeSubDomains directive must be specified,” (ترجمة) «يجب تحديد توجيه includeSubDomains،» و “the preload directive must be specified.” (ترجمة) «يجب تحديد توجيه preload.» (hstspreload.org)

لهذا السبب فإن المثال السابق لمدة عامين (max-age=63072000; includeSubDomains; preload) هو الشكل الذي يقدمه الأشخاص — لاحظ أن هذه هي متطلبات التقديم الدقيقة كما نشرتها hstspreload.org؛ تعامل معها كمعيار حالي، وليس ثابتًا دائمًا، وأعد التحقق من الصفحة الحية قبل التقديم.

من المفيد التمييز بين أربع حالات مختلفة، لأن الناس يخلطون بينها باستمرار:

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

الآن الجزء الذي يحول preload إلى باب ذو اتجاه واحد. من موقع التقديم نفسه: “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (ترجمة) «كن على علم بأن الإدراج في قائمة preload لا يمكن التراجع عنه بسهولة. يمكن إزالة النطاقات، لكن يستغرق شهورًا حتى يصل التغيير إلى المستخدمين مع تحديث Chrome ولا يمكننا تقديم ضمانات بشأن المتصفحات الأخرى.» (hstspreload.org). ونصيحته الخاصة: “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.” (ترجمة) «لا تطلب الإدراج إلا إذا كنت متأكدًا من أنك تستطيع دعم HTTPS لموقعك بالكامل وجميع نطاقاته الفرعية على المدى الطويل.»

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

لماذا صُمم HSTS ليكون مؤلمًا عند حدوث الأعطال

صرامة HSTS ليست خطأ — إنها الضمانة الأمنية بأكملها. يوضح web.dev المقايضة: “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (ترجمة) «من المرجح أن يفشل العملاء الذين أدرجوا موقعك كمضيف HSTS معروف بشدة إذا حدث خطأ في تكوين TLS الخاص بموقعك (مثل شهادة منتهية الصلاحية). تم تصميم HSTS بهذه الطريقة صراحةً لضمان عدم تمكن المهاجمين عبر الشبكة من خداع العملاء للوصول إلى الموقع بدون HTTPS.» (web.dev).

الاستنتاج الذي توصلت إليه Google هو الجملة التي سأكتبها على جبين أي شخص على وشك تفعيل هذا: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (ترجمة) «لا تقم بتمكين HSTS حتى تتأكد من أن تشغيل موقعك قوي بما يكفي لتجنب نشر HTTPS مع أخطاء التحقق من الشهادة.» (web.dev).

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

سيناريوهات الإغلاق الواقعية

الطرق التي يعض بها HSTS في الممارسة العملية تعود دائمًا تقريبًا إلى includeSubDomains أو التحميل المسبق الذي يتقدم على تغطية HTTPS الفعلية الخاصة بك:

• النطاق الفرعي المنسي. قمت بتعيين includeSubDomains على example.com، لكن legacy.example.com (تطبيق قديم، صفحة حالة، أداة بائع) يتحدث HTTP فقط أو لديه شهادة لا تغطيه. كل متصفح رأى الترويسة يرفض الآن تحميل هذا النطاق الفرعي. لم يتغير شيء على ذلك الخادم — وصلت السياسة إليه وكسرته.
• فجوة الشهادة البدل. تغطي شهادة البدل *.example.com نطاق foo.example.com لكن ليس foo.bar.example.com (البدل هو مستوى واحد من تسمية DNS). إذا كان نطاق فرعي أعمق يعتمد على HTTP أو شهادة غير متطابقة، فإن includeSubDomains يقفله.
• الشهادة منتهية الصلاحية على مضيف HSTS. يفشل أتمتة التجديد، تنتهي صلاحية الشهادة، وبدلاً من تحذير يمكن تجاوزه تحصل على موقع معطل لكل من يتذكر متصفحه سياستك — حتى تحصل على شهادة صالحة و يعيدون الاتصال ويتلقون استجابة آمنة جديدة. لا يوجد تجاوز أسرع.
• ندم التحميل المسبق. قمت بالتحميل المسبق، ثم تتطلب حاجة عمل خدمة HTTP فقط تحت النطاق. التراجع عن ذلك هو وظيفتان منفصلتان غير فوريتين، وليس واحدة: تقديم max-age=0 عبر HTTPS يمسح فقط السياسة المتعلمة للعملاء الذين يعيدون الاتصال قبل انتهاء صلاحية max-age القديمة على أي حال، بينما إخراج النطاق من قائمة التحميل المسبق هو إرسال منفصل لا يزال يستغرق دورات إصدار المتصفح — أشهر — للوصول إلى المستخدمين، بغض النظر عن أي شيء تغيره على خادمك.
• تصادمات التطوير المحلي / التدريج. يمكن أن يؤدي التحميل المسبق لـ example.com مع includeSubDomains إلى جعل dev.example.com أو مضيف داخلي بنمط localhost تحت نفس النطاق الأعلى يرفض HTTP، مما يكسر سير العمل المحلي بطرق مفاجئة.

لا شيء من هذه أسباب لتجنب HSTS. إنها أسباب لتدرجه: max-age قصير أولاً، أضف includeSubDomains فقط بعد تدقيق كل نطاق فرعي، واحتفظ بـ preload عندما تكون متأكدًا.

HSTS ليس لعبة ترتيب (ولا يلمس التوحيد القياسي)

لتوضيح الأمر من منظور تحسين محركات البحث (SEO): لا يُعد HSTS إشارة ترتيب. HTTPS نفسه هو إشارة صغيرة عمدًا — وصفته Google بأنه “إشارة خفيفة جدًا” تؤثر على أقل من 1% من الاستعلامات — وHSTS هو طبقة فوق HTTPS، وليس مدخل ترتيب منفصل. كما أنه لا يتحكم مباشرة في التوحيد القياسي أو الفهرسة. توثيق Google الخاص أكثر تحديدًا من عبارة “لا يهم” المسطحة، لكن: Google تفضل HTTPS كمعيار أساسي على صفحة HTTP مكافئة إلا عند وجود شهادة غير صالحة، أو تبعيات صفحة غير آمنة، أو صفحة HTTPS تعيد التوجيه إلى HTTP، أو وسم rel="canonical" من HTTP (Google: دمج عناوين URL المكررة). لا يمكن لـ HSTS إصلاح أو تجاوز أي من ذلك. إنها سياسة من جانب المتصفح دون أي تأثير على منطق التوحيد القياسي في Google — يمكن لشهادة سيئة أو سلسلة إعادة توجيه مكسورة أن تدفع Google نحو معيار HTTP بغض النظر عن ما يقوله رأس HSTS الخاص بك. التوحيد القياسي مدفوع بروابط 301 الخاصة بك، وشهادتك، ووسم rel="canonical"، وروابطك الداخلية — يكسب HSTS مكانه لـ الأمان، وثقة المستخدم، وسد فجوة تجريد SSL — افعل ذلك لهذه الأسباب، وحافظ على روابط 301 والشهادة قوية حقًا، ولن ترى HSTS نفسه أبدًا في تقرير ترتيب في أي من الاتجاهين.

إذا كنت تنفذ انتقال HTTP→HTTPS الأوسع، فإن HSTS هو آخر شيء تقوم بتشغيله، وليس الأول — فهو يأتي بعد استقرار عملية الترحيل، كجزء من انضباط ترحيل الموقع الأوسع.

ملخص الذكاء الاصطناعي

نظرة مختصرة على النسخة المتقدمة:

• HSTS = رأس استجابة Strict-Transport-Security. يخبر المتصفحات باستخدام HTTPS دائمًا لنطاقك، مما يسد “مشكلة الطلب الأول” التي يتركها 301 وحده مفتوحة — طلب HTTP الأولي من زائر جديد غير آمن حتى يتم تشغيل إعادة التوجيه، وهي نافذة تجريد SSL.
• ثلاث توجيهات: max-age (مطلوب، بالثواني؛ يُعاد تعيينه في كل استجابة؛ إزالة الرأس لا تمسح سياسة مكتسبة — يجب تقديم max-age=0 عبر HTTPS بدلاً من ذلك)، وincludeSubDomains (ينطبق على جميع النطاقات الفرعية)، وpreload (علامة للاشتراك في قائمة التحميل المسبق للمتصفح — وجود الرمز، والأهلية، والتقديم، والإدراج الفعلي هي أربع حالات منفصلة).
• جوهر الترقية الداخلية: عندما يفرض المتصفح HSTS، فإنه يعيد كتابة URI إلى HTTPS داخليًا قبل وصول أي طلب إلى الخادم — لا تفرض RFC 6797 رمز حالة محددًا لإعادة الكتابة تلك، على الرغم من أن الأدوات غالبًا ما تعرضها كـ 307 — لذلك لا يراها أي خادم ولا يراها الزاحفون أبدًا. روابط 301 من جانب الخادم لا تزال إلزامية لمحركات البحث وحقوق الروابط. HSTS فوق روابط 301، وليس بدلاً منها أبدًا.
• التحميل المسبق يثبت نطاقك في المتصفح عبر hstspreload.org (يتطلب max-age ≥ 31536000، وincludeSubDomains، وpreload). إنه شبه لا رجعة فيه — الإزالة هي تقديم منفصل يستغرق شهورًا للوصول إلى المستخدمين، متصفحًا بمتصفح.
• مصمم للفشل الصارم: مضيف HSTS مع شهادة مكسورة/منتهية الصلاحية يرفض التحميل، دون إمكانية النقر للمتابعة. Google: “لا تقم بتمكين HSTS حتى تتأكد من أن تشغيل موقعك قوي بما يكفي لتجنب نشر HTTPS مع أخطاء التحقق من الشهادة.”
• سيناريوهات الإغلاق تتركز حول includeSubDomains والتحميل المسبق الذي يتجاوز تغطية HTTPS الخاصة بك: نطاقات فرعية HTTP منسية، وفجوات عمق شهادات البدل، وشهادات منتهية الصلاحية، وندم التحميل المسبق، وتصادمات بيئة التدريج.
• ليست إشارة ترتيب — ولا يمكنها تجاوز التوحيد القياسي. تفضل Google HTTPS كمعيار أساسي إلا عندما تكون الشهادة غير صالحة، أو التبعيات غير آمنة، أو صفحة HTTPS تعيد التوجيه إلى HTTP، أو وسم canonical يشير إلى HTTP — وليس لدى HSTS أي قدرة على إصلاح أو تجاوز أي من ذلك. حافظ على روابط 301 والشهادة ووسوم canonical للقيام بعمل تحسين محركات البحث.

التوثيق الرسمي

توثيق من المصادر الأساسية من فرق المتصفحات والمعايير.

Google / web.dev

• تفعيل HTTPS على خوادمك (web.dev) — قسم HSTS: الترويسة، وتجريد SSL، والتحذير من الفشل الصارم، ونصيحة «لا تفعّل HSTS حتى تتأكد».
• نقل المواقع مع تغيير عناوين URL — لماذا تظل إعادة التوجيه 301 من الخادم إلزامية (عمليات إعادة التوجيه لا تفقد PageRank).
• فهم تجربة الصفحة — موضع HTTPS، وبالتالي HSTS، ضمن تصور Google.

مراجع المعايير والمتصفحات

• MDN — Strict-Transport-Security — الصيغة الكاملة للترويسة، والتوجيهات الثلاثة، وكيف يرقّي المتصفح المخطط.
• RFC 6797 — HTTP Strict Transport Security (HSTS) — المواصفة الأصلية.
• إرسال نطاق إلى قائمة HSTS للتحميل المسبق (hstspreload.org) — متطلبات التحميل المسبق الدقيقة ومحاذير الإزالة، وتحافظ عليها مبادرة Chromium.

اقتباسات من المصدر

تصريحات مسجلة من Google/web.dev وخدمة التحميل المسبق من Chromium. كل رابط يقفز إلى (أو يشير إلى) المقطع المقتبس في صفحة المصدر.

web.dev (Google) — ما يفعله HSTS والتحذيرات

• “Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.” (ترجمة) «استخدم HTTP Strict Transport Security (HSTS) لتجنب تكلفة إعادة التوجيه 301.» الانتقال إلى الاقتباس
• “First, use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” (ترجمة) «أولاً، استخدم Strict Transport Security لإخبار العملاء بأنه يجب عليهم دائمًا الاتصال بخادمك باستخدام HTTPS، حتى عند اتباع مرجع http://. هذا يهزم هجمات مثل SSL Stripping، ويتجنب تكلفة الرحلة ذهابًا وإيابًا لإعادة التوجيه 301.» الانتقال إلى الاقتباس
• “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (ترجمة) «من المرجح أن يفشل العملاء الذين أدرجوا موقعك كمضيف HSTS معروف بشكل صارم إذا كان موقعك يعاني من خطأ في تكوين TLS (مثل شهادة منتهية الصلاحية). تم تصميم HSTS بهذه الطريقة صراحةً لضمان عدم تمكن المهاجمين عبر الشبكة من خداع العملاء للوصول إلى الموقع بدون HTTPS.» الانتقال إلى الاقتباس
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (ترجمة) «لا تقم بتمكين HSTS حتى تتأكد من أن تشغيل موقعك قوي بما يكفي لتجنب نشر HTTPS مع أخطاء التحقق من الشهادة.» الانتقال إلى الاقتباس

خدمة التحميل المسبق من Chromium — hstspreload.org

• “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (ترجمة) «كن على علم بأن الإدراج في قائمة التحميل المسبق لا يمكن التراجع عنه بسهولة. يمكن إزالة النطاقات، لكن يستغرق وصول التغيير إلى المستخدمين عبر تحديث Chrome شهورًا ولا يمكننا تقديم ضمانات بشأن المتصفحات الأخرى.» المصدر
• “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.” (ترجمة) «لا تطلب الإدراج إلا إذا كنت متأكدًا من قدرتك على دعم HTTPS لموقعك بالكامل وجميع نطاقاته الفرعية على المدى الطويل.» المصدر

MDN — سلوك الترويسة

• “Before loading an http URL, the browser checks the domain name against its HSTS hosts list. If the domain name is a case insensitive match for an HSTS host or is a subdomain of one that specified includeSubDomains, then the browser replaces the URL scheme with https.” (ترجمة) «قبل تحميل عنوان URL http، يتحقق المتصفح من اسم النطاق مقابل قائمة مضيفي HSTS الخاصة به. إذا كان اسم النطاق مطابقًا لحالة غير حساسة لمضيف HSTS أو كان نطاقًا فرعيًا لمضيف حدد includeSubDomains، فإن المتصفح يستبدل مخطط عنوان URL بـ https.» المصدر

هل يجب عليّ تمكين HSTS — وإلى أي مدى؟

قم بمراجعته من الأعلى إلى الأسفل. كل “لا” هي علامة توقف، وليست احتمالًا. تمييز واحد قبل أن تبدأ: أرقام max-age الدقيقة أدناه (بضع دقائق للاختبار التجريبي، وسنة للحالة المستقرة) هي توصيات تشغيلية من باتريك، وليست متطلبات بروتوكول — الشرط العددي الصارم الوحيد هو الحد الأدنى للتحميل المسبق في hstspreload.org (max-age ≥ 31536000)، وهو مذكور صراحةً في تلك الخطوة. اضبط فترات المراحل وفقًا لتحملك للمخاطر وإيقاع النشر الخاص بك.

1. هل موقعك بالكامل يعمل بالفعل على HTTPS بشهادة صالحة، وهل استقرت عملية الترحيل؟

• لا → لا تلمس HSTS بعد. أكمل ترحيل HTTPS أولاً: أعد توجيه كل عنوان URL برمز 301، وأصلح المحتوى المختلط، وتحقق في Search Console. HSTS هو المفتاح الأخير، وليس الأول.
• نعم → تابع.

2. هل تجديد الشهادة مؤتمت ومراقب (حتى لا يفاجئك انتهاء الصلاحية)؟

• لا → أصلح ذلك أولاً. على مضيف HSTS، الشهادة المنتهية هي انقطاع كامل، وليست تحذيرًا. قم بإعداد التجديد التلقائي + تنبيهات انتهاء الصلاحية، ثم تابع.
• نعم → تابع. فعّل max-age قصيرًا (مثل بضع دقائق إلى يوم) بدون includeSubDomains بعد، وتأكد من عدم كسر أي شيء.

3. هل قمت بمراجعة كل نطاق فرعي — بما في ذلك www، والتطبيقات القديمة، وصفحات الحالة، ومضيفي البائعين — وتأكدت من أن كلًا منها يقدم HTTPS صالحًا؟

• لا → أبقِ includeSubDomains معطلاً. إضافته الآن سيمتد ليكسر أي نطاق فرعي يعمل بـ HTTP فقط أو بشهادة غير متطابقة.
• نعم → ارفع max-age نحو سنة وأضف includeSubDomains. هذه حالة مستقرة آمنة وقوية لمعظم المواقع.

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

• لا / لست متأكدًا → توقف هنا. max-age=31536000; includeSubDomains (بدون تحميل مسبق) هو وضع ممتاز. المكسب الهامشي للتحميل المسبق لا يستحق عدم رجعيته إذا كنت غير متأكد.
• نعم، متأكد → أضف علامة preload وأرسل في hstspreload.org. تعامل معه كأمر دائم — إزالته تستغرق أشهرًا لتصل إلى المستخدمين.

فرع منفصل وصحيح دائمًا: هل تفعيل HSTS يعني أنني أستطيع إسقاط توجيهات 301 الخاصة بي؟

• أبدًا. الزواحف لا ترى الترقية الداخلية الخاصة بالمتصفح فقط التي يوفرها HSTS. حافظ على توجيهات 301 من جانب الخادم بغض النظر عن مدى تقدمك في هذه الشجرة.

قائمة التحقق لنشر HSTS

اعمل من الأعلى إلى الأسفل — كل مرحلة تسبق التالية. الفترات المرحلية هنا هي توصيات تشغيلية، وليست متطلبات بروتوكول — الرقم الصارم الوحيد هو حد أدنى max-age ≥ 31536000 للتحميل المسبق في المرحلة 3.

قبل تفعيل أي شيء

• الموقع بالكامل (النطاق الجذر + www + جميع النطاقات الفرعية) يقدم HTTPS بشهادة صالحة.
• توجيهات 301 من HTTP إلى HTTPS موجودة من جانب الخادم، واحد لواحد.
• التجديد التلقائي للشهادة مُهيأ و توجد مراقبة/تنبيهات لانتهاء الصلاحية.
• استقر ترحيل HTTP إلى HTTPS (Search Console نظيف، لا انهيار في الترتيب).

المرحلة 1 — أثبت أنها آمنة

• أضف Strict-Transport-Security مع max-age قصير (دقائق إلى يوم).
• لا includeSubDomains بعد. لا preload بعد.
• تأكد من أن الموقع يُحمَّل بشكل طبيعي عبر المتصفحات وأن شيئًا لم ينكسر.

المرحلة 2 — الالتزام

• ارفع max-age إلى 31536000 على الأقل (سنة واحدة).
• راجع كل نطاق فرعي (بما في ذلك www، والقديم، والحالة، والبائع) للتأكد من صحة HTTPS.
• فقط بعد اجتياز تلك المراجعة، أضف includeSubDomains.
• أعد اختبار تحميل كل نطاق فرعي عبر HTTPS.

المرحلة 3 — التحميل المسبق (اختياري، شبه دائم)

• أنت متأكد أنك لن تحتاج أبدًا إلى HTTP تحت هذا النطاق مرة أخرى.
• الترويسة هي max-age=31536000 (أو أكثر) ; includeSubDomains; preload.
• HTTP على المنفذ 80 يعيد التوجيه إلى HTTPS على نفس المضيف.
• أرسل وتأكد من الحالة في hstspreload.org.

صحيح دائمًا — لا تتخطَّه

• تبقى عمليات إعادة التوجيه 301 من جانب الخادم في مكانها (لا يرى الزاحفون الترقية الداخلية الخاصة بالمتصفح فقط).
• لديك خطة تراجع موثقة: max-age=0 المُقدَّم عبر HTTPS يمسح سياسة مكتسبة (غير مُحمَّلة مسبقًا) للعملاء الذين يعيدون الاتصال قبل انتهاء صلاحيتها على أي حال. تتطلب النطاقات المُحمَّلة مسبقًا عملية إزالة منفصلة وأبطأ بدلاً من ذلك.

النماذج الذهنية

1. HSTS طبقة، وليس بديلاً. 301 من جانب الخادم = للزاحفين وحقوق الروابط. الترقية الداخلية من جانب المتصفح (من HSTS، غالبًا ما تظهر كـ 307 على الرغم من أن RFC لا يتطلب هذا الرمز بالضبط) = للبشر العائدين وحماية من تجريد SSL. جماهير مختلفة، وظائف مختلفة. تحتاج دائمًا إلى كليهما؛ HSTS لا يلغي أبدًا 301.

2. HSTS يسد فجوة لا يستطيع 301 سدها. 301 يحمي الطلب الثاني فصاعدًا. الطلب الأول — قبل أن يحدث إعادة التوجيه — لا يزال HTTP. HSTS (للزوار العائدين) والتحميل المسبق (للزوار لأول مرة) هما الشيئان الوحيدان اللذان يسدان تلك النافذة المحددة.

3. صعِّد تدريجيًا، لا تقفز أبدًا. max-age قصير → طويل. رأس بسيط → includeSubDomains (بعد تدقيق النطاقات الفرعية) → preload (فقط إذا كنت متأكدًا). كل درجة قابلة للعكس باستثناء الأخيرة. لا تتخطَّ الدرجات لتوفير الوقت.

4. الصرامة هي الميزة، وهي سلاح ذو حدين. نفس الفشل الصارم الذي يوقف المهاجم يوقفك أيضًا أنت عند كسر شهادة. لذا فإن الشرط المسبق ليس “هل تريد الأمان؟” — الجميع يريده — بل “هل عملية الشهادات لديك قوية بما يكفي لتفشل أبدًا؟”

5. التحميل المسبق هو باب ذو اتجاه واحد. يمكن تخفيف HSTS غير المُحمَّل مسبقًا لعميل في المرة القادمة التي يقدم فيها طلبًا آمنًا ويتلقى max-age=0 — ليس أسرع من ذلك، وفقط للعملاء الذين يعيدون الاتصال. يأخذ التحميل المسبق الأمر خطوة أبعد: الإزالة هي تقديم منفصل يستغرق أشهرًا للوصول إلى المستخدمين، إصدار متصفح بعد إصدار. ضعه في فئة “القرارات التي لا يمكننا التراجع عنها بسهولة” وتعامل معه وفقًا لذلك.

6. HSTS مستقل عن الترتيب — لكنه لا يمكنه إنقاذ إشارة canonical سيئة أيضًا. إنها ليست إشارة ترتيب ولا تتحكم مباشرة في التوحيد القياسي أو الفهرسة. احكم عليها من حيث الأمان والثقة، وليس من حيث مكاسب SEO — لا يوجد أي منها. لكنها ليست شبكة أمان أيضًا: تفضيل Google للـ HTTPS-canonical لا يزال يتراجع بسبب شهادة سيئة، أو تبعيات غير آمنة، أو إعادة توجيه HTTPS→HTTP، أو وسم canonical عبر HTTP، وHSTS ليس لديه القدرة على تجاوز ذلك.

HSTS — ورقة الغش

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

قيم الرأس الشائعة (الأرقام أدناه هي اقتراحات تشغيلية، وليست متطلبات بروتوكول — الحد الأدنى الصارم هو صف التحميل المسبق)

عمليات إعادة التوجيه: أي واحدة، ومن يراها

حقائق سريعة

• يتطلب التحميل المسبق max-age ≥ 31536000 + includeSubDomains + preload — وفق متطلبات hstspreload.org المنشورة حاليًا.
• إزالة التحميل المسبق طلب منفصل يستغرق شهورًا ليصل إلى المستخدمين، متصفحًا بعد متصفح — فتعامل معه كأنه دائم.
• على مضيف HSTS، الشهادة المعطوبة تعني فشلًا صارمًا بلا إمكانية للمتابعة.
• HSTS ليس إشارة ترتيب، ولا يحل محل عمليات إعادة التوجيه 301.

تعيين ترويسة HSTS

أضف الترويسة إلى كتلة خادم HTTPS فقط، وابدأ بقيمة max-age قصيرة حتى تتأكد من عدم تعطل أي شيء. لا تضف ; preload إلا عندما تنوي الإرسال إلى hstspreload.org — إذ يصعب التراجع عنه بشدة.

Apache (.htaccess)

<IfModule mod_headers.c>
  # Start short (300s) to prove it's safe; raise to 31536000 once confident.
  Header always set Strict-Transport-Security "max-age=300"
  # Full posture once every subdomain is verified HTTPS:
  # Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  # Only add ; preload when submitting to hstspreload.org:
  # Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Nginx

# On the HTTPS (listen 443) server block:
add_header Strict-Transport-Security "max-age=300" always;
# Full posture once subdomains are verified:
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Preload shape (near-irreversible):
# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

التحقق من تعيين HSTS وقراءة قيمته

macOS / Linux

# Print only the Strict-Transport-Security response header
curl -sI https://example.com/ | grep -i strict-transport-security
# → strict-transport-security: max-age=31536000; includeSubDomains

Windows (PowerShell)

# Same check in PowerShell
(Invoke-WebRequest -Uri "https://example.com/" -Method Head).Headers["Strict-Transport-Security"]

فحص إدخال HSTS ومسحه في Chrome (DevTools / net-internals)

إذا كنت تختبر وقد «تعلّم» المتصفح سياسة HSTS تحتاج إلى مسحها:

1. Open a new tab and visit:  chrome://net-internals/#hsts
2. Under "Query HSTS/PKP domain", enter your host to see the stored policy.
3. Under "Delete domain security policies", enter the host and Delete.
   (This clears the *learned* policy — it does NOT remove a *preloaded* domain,
   which lives in the browser binary and can't be cleared this way.)

استخدم ذلك للتأكد من أن الترويسة تُخزّن بالفعل ولإعادة ضبط مضيف اختباري — لا بوصفه إصلاحًا للإنتاج، حيث يكون الحل هو تقديم max-age=0 فعليًا عبر HTTPS (فمجرد إزالة الترويسة لا يمسح سياسة سبق أن تعلّمها العميل؛ ولا يسري المسح إلا عندما يعيد ذلك العميل الاتصال ويتلقى استجابة max-age=0).

أخطاء HSTS المؤذية

1. حذف عمليات إعادة التوجيه 301s لأن «HSTS يتولى الأمر». هذا هو الخطأ التقليدي. إعادة توجيه HSTS ترقية داخلية في المتصفح فقط، ولا تراها برامج الزحف. إذا أزلت عمليات 301s من الخادم، تفقد محركات البحث الإشارة التي توحّد عملية النقل. احتفظ بالاثنتين دائمًا.

2. تفعيل includeSubDomains قبل تدقيق النطاقات الفرعية. هذه أكثر الطرق شيوعًا لتعطيل نطاق فرعي. إذا كان أي نطاق فرعي — تطبيقًا قديمًا، أو صفحة حالة، أو مضيف مورّد، أو حتى www — لا يعمل عبر HTTPS صالح، فستمتد السياسة إليه وتعطله لدى كل متصفح رأى الترويسة.

3. القفز مباشرة إلى max-age لمدة سنة (أو إلى التحميل المسبق) في اليوم الأول. لا توجد شبكة أمان. ابدأ بمدة قصيرة (max-age=300)، وتأكد من عدم تعطل شيء، ثم زدها تدريجيًا. تعيين max-age طويلة على موقع سيئ الإعداد انقطاع تسببه لنفسك ويظل محفوظًا في المتصفحات عامًا كاملًا.

4. التحميل المسبق قبل HTTPS محكم حقًا. التحميل المسبق شبه لا رجعة فيه — إزالته تستغرق أشهرًا. صياغة Google نفسها: لا تفعّل HSTS حتى تتأكد من متانة تشغيل موقعك بما يكفي. التحميل المسبق يضاعف هذه المخاطر.

5. التعامل مع شهادة منتهية الصلاحية كمشكلة بسيطة. على موقع غير مزود بـ HSTS، الشهادة المنتهية هي تحذير يمكن تجاوزه. على مضيف HSTS، إنها انقطاع كامل بدون إمكانية النقر للمتابعة. إذا قمت بتمكين HSTS، فإن أتمتة تجديد الشهادات وتنبيهات انتهاء الصلاحية تتوقف عن كونها رفاهية.

6. تعيين الترويسة على استجابة HTTP. تتجاهل المتصفحات HSTS المُرسل عبر HTTP (بالتصميم — يمكن للمهاجم حقنه أو إزالته). يجب إرساله على استجابة HTTPS ليُحتسب.

7. نسيان حد عمق الشهادة البدل. شهادة بدل *.example.com لا تغطي foo.bar.example.com. قم بتمكين includeSubDomains وأي نطاق فرعي أعمق يعتمد على تلك الشهادة سيُحظر.

دليل الحوادث: مضيف HSTS محظور

1. تأكد من الفشل من شبكة نظيفة وأكثر من متصفح واحد. سجل أسماء المضيفات المتأثرة وخطأ الشهادة الدقيق. يمكن لسياسة HSTS المخزنة أن تجعل الأعراض مختلفة بين الزوار العائدين والزوار لأول مرة.
2. استعد HTTPS صالحًا أولاً. إذا كانت الشهادة منتهية، أو غير متطابقة، أو تفتقد إلى شهادة وسيطة، فجددها أو استبدلها وانشر السلسلة الكاملة. لن يقدم متصفح HSTS تجاوزًا آمنًا عبر HTTP.
3. حدد نطاق السياسة. افحص ترويسة Strict-Transport-Security الحية وحدد ما إذا كان includeSubDomains أو التحميل المسبق يوسع نطاق الانقطاع إلى ما بعد اسم المضيف الذي أرسلها.
4. جرد كل نطاق فرعي متأثر. بالنسبة لمضيف HTTP منسي، ضع شهادة صالحة ونقطة نهاية HTTPS أمامه قبل تحديد ما إذا كنت ستبقي الخدمة أو تنقلها أو تعيد توجيهها.
5. صحح السياسة فقط بعد استعادة الوصول. إذا كان النطاق غير آمن، قلل أو أزل الترويسة على استجابات HTTPS. لا يمسح ذلك فورًا سياسة مخزنة بالفعل في المتصفحات، وإزالة التحميل المسبق عملية منفصلة وبطيئة.
6. تحقق من الاسترداد. اختبر النطاق الجذر، وwww، وكل نطاق فرعي متأثر لسلسلة صالحة، واسم مضيف صحيح، وإعادة توجيه HTTP→HTTPS من خطوة واحدة، وترويسة HSTS المقصودة. حافظ على مراقبة انتهاء صلاحية الشهادة على نفس الجرد.

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

تدقيق سياسة HSTS حية

Act as a security-minded technical SEO. Review this Strict-Transport-Security
header, the HTTP redirect response, and the supplied subdomain inventory.

For the header, parse max-age, includeSubDomains, and preload. Explain the effective
scope, identify subdomains whose HTTPS or certificate coverage is unproven, and
separate browser-side HSTS behavior from the server-side 301 search engines need. Use
GET requests (HEAD can behave differently on some servers/clients), and record which
client or tool produced each observation and its version, since internal-redirect
representation is client/tool-specific rather than a fixed protocol value.

Recommend the next rollout stage: keep a short max-age canary, lengthen max-age,
add includeSubDomains, or consider preload. Do not recommend preload unless the
evidence shows a valid certificate, same-host HTTP→HTTPS redirects, HTTPS on every
subdomain, max-age of at least 31536000, includeSubDomains, and the preload token.

Return: observed configuration, risks, blocking evidence, next action, rollback
constraint, and exact validation checks.

فرز انقطاع HSTS

Given the affected hostnames, browser error, certificate details, DNS/CDN layout,
and live response headers, identify whether this is an expired certificate, hostname
mismatch, incomplete chain, includeSubDomains spillover, or preload issue. Prioritize
restoring valid HTTPS. Explain why removing a header does not immediately erase a
cached browser policy, then provide recovery and verification steps.

مجموعة أدوات فحص HSTS

• HTTP Header Checker — افحص ترويسة Strict-Transport-Security الحية وتأكد من ظهورها على استجابات HTTPS.
• curl -I — قارن إعادة توجيه HTTP مع ترويسة HTTPS دون الاعتماد على حالة HSTS المخزنة في المتصفح.
• أدوات مطور المتصفح — تأكد من ترويسات الاستجابة النهائية وخطأ الشهادة الذي يراه عميل حقيقي.
• حالة تحميل HSTS المسبق — تحقق من متطلبات التقديم وما إذا كان النطاق ممثلًا بالفعل في عملية التحميل المسبق.

استخدم طريقتين على الأقل: يُظهر إخراج سطر الأوامر استجابة الخادم، بينما يكشف المتصفح أيضًا عن فرض جانب العميل وفشل الشهادة الصارم. فضل GET على HEAD عند مقارنة الأدوات — بعض الخوادم والعملاء يمثلون الاثنين بشكل مختلف — ولاحظ العميل/الأداة/الإصدار الدقيق خلف كل قراءة.

اختبارات نشر HSTS المرحلية

الاختبار 0: مصفوفة الحالة (شغّل هذا قبل تجهيز التغييرات)

حالة HSTS ليست حقيقة واحدة — إنها عدة حالات مستقلة يمكن أن تتعارض. تتبعها بشكل منفصل، لكل اسم مضيف:

سجّل العميل والأداة والإصدار لكل ملاحظة — تمثيل إعادة التوجيه الداخلي وتفاصيل تنفيذ HSTS تختلف عبر المتصفحات والزواحف وأدوات سطر الأوامر، والقراءة القديمة من عميل واحد قد تبدو كتناقض غير حقيقي.

الاختبار 1: كاناري max-age قصير

• الغرض: إثبات أن الترويسة تُصدر فقط من استجابات HTTPS السليمة قبل إلزام العملاء بسياسة طويلة.
• الطريقة: فحص القوالب والمضيفات التمثيلية باستخدام HTTP Header Checker وcurl -I؛ مقارنة القيمة المنشورة مع تكوين الكاناري المعتمد.
• النتيجة المتوقعة: استجابات HTTPS تحمل max-age القصير المقصود؛ HTTP لا يزال يعيد توجيهًا دائمًا من جانب الخادم إلى HTTPS.
• مشغل الفشل: ترويسات مفقودة أو مكررة، مدة طويلة غير متوقعة، أخطاء شهادة، أو أي حلقة إعادة توجيه.
• الإجراء التالي: إصلاح الترويسة أو نقطة نهاية HTTPS وإبقاء الطرح في مرحلة الكاناري.

الاختبار 2: جاهزية includeSubDomains

• الغرض: منع سياسة أصلية من قفل اسم مضيف منسي.
• الطريقة: اختبار كل اسم DNS مضيف في جرد النطاقات الفرعية المُدار للحصول على استجابة HTTPS صالحة، واسم شهادة صحيح، وسلسلة كاملة.
• النتيجة المتوقعة: كل نطاق فرعي ضمن النطاق يعمل عبر HTTPS، بما في ذلك المضيفات القديمة والمورّدين والتطوير والمستويات الأعمق.
• مشغل الفشل: أي خدمة HTTP فقط، شهادة منتهية أو غير متطابقة، أو اسم مضيف مفقود من الجرد.
• الإجراء التالي: معالجة أو نقل المضيف قبل إضافة includeSubDomains.

الاختبار 3: جاهزية التحميل المسبق

• الغرض: التحقق من أن السياسة شبه الدائمة تلبي متطلبات التقديم الموثقة.
• الطريقة: تأكيد شهادة صالحة، إعادة توجيه HTTP→HTTPS على نفس المضيف، HTTPS على جميع النطاقات الفرعية، وترويسة جذرية مع max-age لا تقل عن 31536000، وincludeSubDomains، وpreload.
• النتيجة المتوقعة: كل متطلب ينجح وتقبل المنظمة مسار الإزالة البطيء.
• مشغل الفشل: أي متطلب تقني فاشل أو حاجة غير محلولة لنطاق فرعي HTTP فقط.
• الإجراء التالي: لا تقدم؛ ابقَ على السياسة المرحلية القابلة للعكس.

موارد تستحق وقتك

محادثاتي

• السلامة خير من الندامة مع HTTPS — SMX East 2016 (SlideShare) — غوصي العميق في TLS، وفشل تنفيذ HTTPS الشائع، ومزالق الترحيل التي يغلقها HSTS ويمكن أن يضخمها. (ينطبق إخلاء المسؤولية الدائم: إنه فهمي لهذه الأنظمة، وإحصائيات التبني فيه من عام 2016.)

كتاباتي ذات الصلة

• الدليل المبتدئ لتحسين محركات البحث التقني — حيث يتناسب HTTPS وHSTS مع الصورة الأكبر.

من حول الصناعة

• فعّل HTTPS على خوادمك (web.dev) — إرشادات Google الخاصة بـ HSTS: الترويسة، وإزالة SSL، وتحذير الفشل الصارم.
• MDN — Strict-Transport-Security — المرجع الموثوق للترويسة: الصيغة، والتوجيهات، وسلوك ترقية المخطط.
• تقديم قائمة HSTS المسبقة (hstspreload.org) — متطلبات التحميل المسبق لمشروع Chromium وتحذيرات شبه عدم الرجوع.
• RFC 6797 — HTTP Strict Transport Security — المواصفة الأصلية، عندما تحتاج إلى الصياغة الدقيقة للتوجيه.
• HSTS — ما هو وكيف تستخدمه (Kinsta) — دليل تنفيذ عملي يغطي إعادة التوجيه الداخلية على مستوى المتصفح، وقائمة التحميل المسبق، ومخاطر الاحتجاز.
• اختبار خادم SSL Labs (Qualys) — قيّم تكوين TLS الخاص بك وتأكد من تقديم HSTS بشكل صحيح.

إحصائيات وحقائق قاطعة تستحق الاستشهاد

• يتطلب التحميل المسبق max-age ≥ 31536000 (سنة واحدة)، وincludeSubDomains، و preload. الحد الأدنى الدقيق وغير القابل للتفاوض لتقديم القائمة المدمجة في المتصفح. المصدر
• إزالة التحميل المسبق تستغرق شهورًا للوصول إلى المستخدمين. من خدمة التقديم: “inclusion in the preload list cannot easily be undone… it takes months for a change to reach users with a Chrome update.” (ترجمة) «لا يمكن التراجع عن الإدراج في قائمة التحميل المسبق بسهولة… يستغرق الأمر شهورًا حتى يصل التغيير إلى المستخدمين عبر تحديث Chrome.» هذا هو الرقم الذي يجعل التحميل المسبق بابًا باتجاه واحد. المصدر
• تتعطل مضيفات HSTS بشدة عند أي خطأ في TLS. web.dev: “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration.” (ترجمة) «من المرجح أن يفشل العملاء الذين أدرجوا موقعك كمضيف HSTS معروف فشلًا صارمًا إذا حدث خطأ في تكوين TLS الخاص بموقعك.» لا نقرة للمتابعة — الشهادة المنتهية تصبح انقطاعًا في الخدمة. المصدر
• HTTPS نفسه “a very lightweight signal—affecting fewer than 1% of global queries.” (ترجمة) «إشارة خفيفة جدًا—تؤثر على أقل من 1% من الاستعلامات العالمية.» صياغة Google الخاصة — وHSTS طبقة فوق HTTPS، وليس مدخل ترتيب منفصل، لذا فإن وزنه في تحسين محركات البحث صفر فعليًا. اضبط التوقعات وفقًا لذلك. المصدر

اختبر نفسك: HSTS

خمسة أسئلة سريعة حول HSTS. اختر إجابة لكل سؤال، ثم تحقق.

سجل التغييرات