upgrade-insecure-requests: كيف تُرقّي الطلبات غير الآمنة قبل إرسالها

upgrade-insecure-requests توجيه في Content-Security-Policy يعيد كتابة عنوان http:// إلى https:// قبل أن يرسل المتصفح الطلب. يكفي رأس استجابة واحد لتُجلب كل الموارد الفرعية http:// في الصفحة عبر https://. إنه إعادة كتابة، لا إصلاح: إذا لم يستجب العنوان الآمن، يفشل الطلب ولا رجعة إلى HTTP. ولا يغني عن HSTS، لأن الروابط إلى نطاق آخر لا تُمس.

ما الذي يغيّره upgrade-insecure-requests

يعمل التوجيه قبل حجب المحتوى المختلط. تقول مواصفة W3C إن الآلية ترقّي طلبات الموارد «غير الآمنة مسبقًا» إلى نقل آمن «before fetching them»، وإن إعادة الكتابة تحدث قبل فحوص المحتوى المختلط وCSP. لذلك لا يُبلّغ عن الطلب المرقّى كمحتوى مختلط (Upgrade Insecure Requests، Candidate Recommendation في 8 أكتوبر 2015، اطُّلعت عليه في 2026-11-03). وتصف MDN السلوك نفسه وتصنّف الميزة ضمن Baseline متاحة على نطاق واسع منذ أبريل 2018 (MDN، اطُّلعت عليه في 2026-11-03).

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

السطر الرابع هو الأكثر إغفالًا. الانتقال داخل الموقع نفسه يُرقّى، أما الانتقال إلى نطاق آخر فلا (المواصفة نفسها، القسم 1.2.2، اطُّلعت عليه في 2026-11-03). لهذا لا يحل هذا التوجيه محل HSTS.

كيف تضيف upgrade-insecure-requests

رأس استجابة واحد يكفي. ضعه على كل استجابة HTML قد تحمل عنوانًا غير آمن.

Content-Security-Policy: upgrade-insecure-requests

إذا لم تسمح الاستضافة بتعديل الرؤوس، فوسم meta بديل. لكنه يغطي المستند الذي يحمله فقط.

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

لا تضف block-all-mixed-content إلى جانبه. تصنّف MDN هذا التوجيه كمتقادم، وتقول مواصفة W3C إن upgrade-insecure-requests يُقيَّم أولًا، لذا لا يفعل block-all-mixed-content شيئًا عند وجودهما معًا (MDN، اطُّلعت عليه في 2026-11-03). اختر واحدًا.

اعثر على العناوين غير الآمنة قبل التطبيق

ابدأ بالعدّ. الأمران أدناه يستغرقان دقيقة وينتجان قائمة قابلة للمراجعة. لا يعثران على كل شيء: العناوين التي يبنيها JavaScript وتلك المكتوبة داخل CSS لا تظهر في الأمر الثاني.

# 1. هل ترسل الصفحة التوجيه أصلًا؟
curl -sI https://example.com | grep -i '^content-security-policy'

# 2. أي موارد لا تزال على http://؟
curl -s https://example.com \
  | grep -oE '(src|href)="http://[^"]+' \
  | sort -u

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

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

Content-Security-Policy-Report-Only: upgrade-insecure-requests; report-uri /csp-reports

report-uri هو الآلية الأقدم. report-to هو إعداد النقطة الأحدث، لكنهما ليسا متبادلين في كل استضافة. لم نختبر تسليم التقارير على كل CDN، فتأكد من وصول تقرير إلى نقطتك قبل أن تعتبر التقرير الفارغ دليلًا على عدم وجود مشكلة.

أين يتوقف التوجيه

ثلاثة حدود أهم من الصياغة.

1. الانتقال إلى طرف ثالث. الرابط إلى نطاق آخر عبر http:// لا يُرقّى. يغادر الزائر صفحتك عبر HTTP، وهذا التوجيه لا يمنعه.
2. غياب HTTPS. لا يوجد بديل. إذا لم يستجب العنوان المرقّى عبر HTTPS، يفشل الطلب وتفقد الصفحة ذلك المورد.
3. HSTS. لا يحل التوجيه محل Strict-Transport-Security. يحمي HSTS الزيارات المستقبلية وأول انتقال، بينما يحمي هذا التوجيه طلبات الصفحة الحالية.

تعالج المواصفة اتصالات WebSocket بشكل منفصل: الاتصال غير الآمن ws:// يُرقّى إلى wss:// عند تطبيق التوجيه (القسم 5، اطُّلعت عليه في 2026-11-03). لم نختبر نقطة WebSocket حقيقية، فنسجّل ذلك كسلوك موثّق لا كنتيجة مقيسة.

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

ترتيب ترحيل لا يكسر الصفحة

هذا هو الترتيب الذي سأستخدمه في موقع يحمل عناوين http:// مكتوبة يدويًا منذ سنوات.

1. اجرد القوالب. شغّل الأمرين على الصفحات المهمة، لا على الرئيسية فقط، واحفظ الناتج في ملف.
2. أصلح ما تتحكم به. انقل صور الموقع نفسه وخطوطه وسكربتاته إلى HTTPS أولًا. هذه الأعطال مرئية وتُصلح في نشر واحد.
3. افحص كل طرف ثالث. اطلب عنوان HTTPS. إن لم يوفّره المورّد، استبدل المورد أو احذفه قبل التطبيق.
4. وضع التقرير لدورة زحف واحدة. قارن التقارير بالجرد. العنوان الذي يظهر في التقارير ولا يظهر في الجرد هو عنوان فات مراجعة الشيفرة.
5. طبّق ثم تحقق. انتقل إلى رأس التطبيق، وأعد التحميل مع فتح لوحة الشبكة، وتأكد من عدم بقاء أي طلب على http://. اترك HSTS قرارًا منفصلًا.

المُخرَج هو الجرد ومقارنته بالتقارير، لا سطر الرأس. الرأس يُضاف في عشر ثوانٍ. الجرد هو العمل.

ثلاث طرق للخطأ

الثلاثة تفشل بهدوء عند أول تحميل، واثنان منها يبدوان كمشكلة CDN.

1. التطبيق قبل دعم المورّد لـ HTTPS. يُعاد كتابة الطلب، ولا يستجيب خادم المورّد على المنفذ 443، فيختفي المورد. لا إعادة محاولة عبر HTTP.
2. الاعتقاد بأنه يغطي روابط المستوى الأعلى. رابط إلى موقع شريك عبر http:// يوصل الزائر عبر HTTP. هذا دور HSTS.
3. جمع توجيهي CSP. block-all-mixed-content متقادم ولا يفعل شيئًا عند وجود توجيه الترقية. سطران يبدوان أكثر أمانًا، لكن السطر الواحد هو الإعداد الصحيح.

متى لا تستخدمه

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

لا نستطيع أن نقول كم من الزيارات تخسره عند فشل الترقية. يعتمد ذلك على المورد الذي يفشل وعلى ما تفعله الصفحة بدونه. قِس الصفحة، لا الرأس.

أسئلة شائعة

هل هو نفسه HSTS؟

لا. يخبر HSTS المتصفح باستخدام HTTPS في الطلبات المستقبلية إلى مضيف معيّن. أما upgrade-insecure-requests فيعيد كتابة الطلبات غير الآمنة في الصفحة الحالية. تفصل مواصفة W3C بين الاثنين وتقول إن هذا التوجيه لا يحل محل HSTS (اطُّلعت عليها في 2026-11-03).

هل يزيل تحذيرات المحتوى المختلط؟

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

هل يعمل داخل وسم meta؟

نعم، في المستند الذي يحمله. رأس الاستجابة يغطي كل استجابات HTML التي تعدّها، أما وسم meta فيغطي صفحته فقط.

ما هو رأس الطلب Upgrade-Insecure-Requests؟

إنه رأس آخر. يرسل المتصفح Upgrade-Insecure-Requests: 1 ليعلن أنه قادر على الترقية. ويمكن للخادم استخدامه لإرجاع تحويل 307. إنه كشف قدرات، لا توجيه التطبيق.

هل يعمل مع CDN؟

نعم، إذا مرّر الـ CDN رأس الاستجابة. افحص استجابة واحدة بـ curl -sI بعد النشر. لم نختبر معالجة الرؤوس عند كل CDN، فتحقق من حافتك أنت.

هل يحترمه Googlebot؟

لم نختبر Googlebot ولا أي زاحف ذكاء اصطناعي. أكّد من سجلاتك أو من جلب مع عرض قبل الاعتماد عليه.

الخطوة التالية

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