المحتوى المختلط

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

ما المحتوى المختلط؟

عندما تنقل موقعًا إلى HTTPS تُحمّل الصفحة نفسها بأمان، لكنها ليست HTML وحده؛ فهي تجلب صورًا وبرامج نصية وأوراق أنماط وخطوطًا ومقاطع فيديو، وأحيانًا إطارات مضمنة، من أماكن أخرى. إذا ظل أي من هذه الأجزاء مطلوبًا عبر http:// العادي، صار لديك محتوى مختلط: صفحة آمنة تحمل شحنة غير آمنة.

وكما يوضح Google: “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (ترجمة) «يكون في الصفحة محتوى مختلط عندما يُحمّل HTML الأولي عبر اتصال HTTPS آمن، بينما تُحمّل موارد أخرى، مثل الصور والفيديو وأوراق الأنماط والبرامج النصية، عبر اتصال HTTP غير آمن».

تكمن المشكلة في أن الأجزاء غير الآمنة تعيد فتح الثغرة التي أغلقها HTTPS. يستطيع من يراقب الشبكة بين الزائر والخادم قراءة طلبات http:// أو العبث بها، فتَعِد علامة القفل في شريط العنوان بأمان أكبر مما توفره الصفحة فعلًا.

النوعان وكيف تتعامل المتصفحات معهما

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

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

أما الرابط العادي (<a href="http://…">) إلى صفحة HTTP فليس محتوى مختلطًا؛ إنه ينقلك إلى مكان آخر ولا يحمّل جزءًا غير آمن داخل صفحتك الآمنة.

كيفية إصلاحه

الإصلاح واحد في معظم الحالات: اجعل المورد غير الآمن يُحمّل عبر HTTPS. غيّر http:// إلى https:// في المرجع، أو استخدم مسارًا لا يثبت البروتوكول. يكون المورد متاحًا عبر HTTPS غالبًا، لكن مرجع http:// قديمًا بقي في قالب أو إضافة أو قاعدة البيانات.

ولإنشاء شبكة أمان لما فاتك، أضف سطر الإعداد upgrade-insecure-requests الذي يطلب من المتصفح إعادة كتابة طلبات الموارد المتبقية من http:// إلى https:// قبل إرسالها. إنه حاجز احتياطي ممتاز، لكنه ليس مبررًا لترك المصدر الحقيقي بلا تنظيف.

للاطلاع على الصورة الكاملة — قوائم الموارد التي تحظرها المتصفحات، والكشف على نطاق واسع عبر DevTools وتقارير CSP، والتوجيهين upgrade-insecure-requests و block-all-mixed-content، وسبب إعادة CMS للمشكلة، وعلاقتها بـHSTS — انتقل إلى تبويب Advanced.

الخلاصة — المحتوى المختلط هو أن تحمّل صفحة HTTPS موردًا فرعيًا عبر HTTP. يصنفه معيار W3C والمتصفحات حاليًا إلى محتوى قابل للترقية وآخر قابل للحظر، بينما يظل التقسيم الأقدم إلى نشط وسلبي مفيدًا لفهم حجم الضرر. توجد استثناءات: صور CORS ومرشحات srcset/picture والطلبات إلى مضيفات بعناوين IP قابلة للحظر، مع أن img src العادي قابل للترقية. يُحظر المحتوى النشط، مثل البرامج النصية وأوراق الأنماط والإطارات وXMLHttpRequest/fetch، لذلك أصلحه أولًا. أما الصور والصوت والفيديو فكانت تُحمّل مع خفض مؤشر الأمان، وتزداد الآن ترقيتها أو حظرها تلقائيًا. الروابط والتنقلات العليا إلى HTTP ليست محتوى مختلطًا، وكذلك التنزيلات غير الآمنة حد أمني منفصل. افحص المصدر المسترجع وحالة التشغيل المعروضة وجلسات المستخدمين الفعلية بالزحف ووحدة Chrome DevTools وتقارير Content-Security-Policy-Report-Only. تحقق أولًا من عمل البديل عبر https://، ثم حدّث كل مورد. يعيد Content-Security-Policy: upgrade-insecure-requests كتابة الطلبات المشمولة، حتى العابرة للأصول، قبل إرسالها وقبل فحوص المحتوى المختلط وCSP؛ لكنه شبكة أمان بلا رجوع إلى HTTP، ولا يرقّي التنقل الأعلى إلى أصل خارجي، فلا يحل محل HSTS. ووضع التوجيه نفسه في report-only لا يفعل شيئًا. انسخ قاعدة بيانات CMS احتياطيًا واختبر الاستبدال قبل تنفيذه لأن الاستبدال الساذج قد يفسد البيانات المسلسلة، وراقب الإضافات والقوالب وعمال الخدمة والذاكرات المؤقتة ووسوم الإعلانات والتحليلات على نطاق الموقع.

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

ما الذي يُعد محتوى مختلطًا، وما الذي لا يُعد كذلك؟

نطاق المحتوى المختلط محدد بدقة: يتعلق بالموارد الفرعية التي تحمّلها الصفحة، لا بالروابط الموجودة فيها. ووفق تعريف Google: “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (ترجمة) «تحتوي الصفحة على محتوى مختلط عندما يُحمّل HTML الأولي عبر اتصال HTTPS آمن، بينما تُحمّل موارد أخرى، مثل الصور والفيديو وأوراق الأنماط والبرامج النصية، عبر اتصال HTTP غير آمن». Evidence for this claim Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Scope: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Confidence: high · Verified: 2026-07-14 MDN: Mixed content

قد توحي وسمة الرابط بطمأنينة زائفة. فالرابط <a href="http://…"> إلى صفحة HTTP ليس محتوى مختلطًا؛ إنه ينقل المستخدم إلى مستند جديد ولا يحمّل موردًا غير آمن داخل الصفحة الآمنة الحالية. وينطبق ذلك على أي تنقل في المستوى الأعلى إلى HTTP، لا على نقرات الروابط وحدها.

مع ذلك، يُستحسن توجيه الروابط الصادرة إلى وجهات HTTPS. وفق القيمة الافتراضية الحديثة لـReferrer-Policy، أي strict-origin-when-cross-origin، قد يؤدي النقر من HTTPS إلى HTTP إلى إسقاط ترويسة Referer وتشويه تحليلات الإحالة. لكن ذلك يعتمد على السياسة والمتصفح وليس قاعدة مطلقة؛ فقد ترسل صفحة أو وسيط/CDN إحالة إذا ضبطت Referrer-Policy أقل تشددًا. افحص السياسة الفعلية قبل تقدير البيانات المفقودة. وفي كل الأحوال، هذه مشكلة منفصلة عن المحتوى المختلط.

النشط مقابل السلبي: التمييز الذي يحدد الأولويات

تصنف وثائق المتصفحات وW3C الحديثة المحتوى المختلط أساسًا إلى قابل للترقية وقابل للحظر: موارد يعيد المتصفح طلبها بهدوء عبر HTTPS، وأخرى يرفضها تمامًا. يظل تقسيم نشط/سلبي اختصارًا مفيدًا لسبب رسم هذا الحد، أي مقدار الصفحة الذي قد يعرّضه المورد للخطر، وهو أيضًا إطار شرح Google. لكنه ليس التصنيف الرسمي الحالي عند تحليل نوع مورد بعينه؛ راجع الاستثناءات بعد القائمتين.

تصنف المتصفحات المحتوى المختلط بحسب مقدار الصفحة الذي قد يعرّضه المورد غير الآمن للخطر. تقول Google: “Active mixed content poses a greater threat than passive mixed content.” (ترجمة) «يشكل المحتوى المختلط النشط تهديدًا أكبر من المحتوى المختلط السلبي». ينبغي لهذه الجملة أن تحدد ترتيب المعالجة.

يتفاعل المحتوى المختلط النشط مع الصفحة كلها وقد يسيطر عليها. تصفه Google بأنه “scripts, stylesheets, iframes, and any other code the browser can download and execute.” (ترجمة) «البرامج النصية وأوراق الأنماط والإطارات وأي شيفرة أخرى يستطيع المتصفح تنزيلها وتنفيذها». وتشمل قائمته عمليًا:

• <script src="http://…"> — أسوأ الحالات؛ إذ يمكن لبرنامج نصي مُعترض إعادة كتابة DOM بالكامل أو تسريب بيانات النماذج أو حقن محتوى.
• <link rel="stylesheet" href="http://…"> — يمكن لـCSS إخفاء أي عنصر أو نقله أو تغطيته، لذا يُعامل كنشط.
• <iframe src="http://…"> — مستند غير آمن مضمن داخل مستندك الآمن.
• طلبات XMLHttpRequest / fetch() إلى http:// — بيانات غير آمنة تتصرف الصفحة بناء عليها.
• خطوط الويب وموارد <object>/<embed> وأنواع <link> التي تجلب محتوى تنفيذيًا أو متحكمًا في التخطيط.

لأن المورد النشط الذي عُبث به يستطيع إعادة كتابة الصفحة، تقول Google: “Most browsers already block this type of content by default to protect users.” (ترجمة) «تحظر معظم المتصفحات هذا النوع من المحتوى افتراضيًا لحماية المستخدمين». لذلك يتسبب المحتوى النشط في أعطال ظاهرة بعد الترحيل: ورقة أنماط محظورة تزيل التصميم، وبرنامج نصي محظور يوقف التفاعل، وإطار محظور يترك فراغًا. أصلح النشط أولًا؛ فهو عيب وظيفي لا مجرد تنبيه أمني.

المحتوى المختلط السلبي (المعروض)، الذي تصفه Google بأنه “including images, video, and audio” (ترجمة) «بما في ذلك الصور والفيديو والصوت»، “doesn’t interact with the rest of the page.” (ترجمة) «لا يتفاعل مع بقية الصفحة». يمكن تبديل صورة معترضة لكنها لا تسيطر على المستند. لذلك كانت المتصفحات تحمّله وتخفض مؤشر الأمان. وتقول Google: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” (ترجمة) «حتى وقت قريب كان المحتوى المختلط السلبي يُحمّل في جميع المتصفحات لأن حظره كان سيعطل مواقع كثيرة، وهذا بدأ يتغير الآن». الاتجاه هو الترقية التلقائية إلى HTTPS وحظر ما يتعذر ترقيته، فلا تفترض أن السلبي غير ضار.

استثناءات لا يغطيها تقسيم النشط والسلبي

يشمل الحد الفاصل بين القابل للترقية والقابل للحظر استثناءات لا تتبع قاعدة «الصور تُرقّى والبرامج النصية تُحظر». وهذه أكثر الحالات التي تسبب أخطاء عملية:

• طلبات الصور المفعّل لها CORS تفشل قسرًا ولا تُرقّى. تكون صورة <img src="http://…"> العادية قابلة للترقية، لكن الطلب الذي يحدد crossorigin يعامله خوارزم المحتوى المختلط على نحو مختلف ويفشله.
• مرشحات srcset و<picture> قابلة للحظر لا للترقية. قد تختلف معاملة الصورة نفسها عند طلبها بآلية صور متجاوبة بدل src عادي.
• المضيفات المعطاة بعناوين IP تُحظر ولا تُرقّى حتى لنوع مورد قابل للترقية؛ فلا يحظى http://203.0.113.5/logo.png بمعاملة النظير ذي اسم النطاق.
• السياقات المتداخلة والعمال مشمولة. تنطبق الفحوص داخل الإطارات وعمال الخدمة والعمال المشتركين أيضًا.
• للأصول المحلية وعناوين loopback وضع خاص. تُعد localhost وعناوين loopback وسياقات file:// «أصولًا يحتمل الوثوق بها» في المواصفة حتى من دون TLS، لذلك لا يكفي اختبار HTTP مقابل HTTPS في بيئة التطوير المحلية.
• التنزيلات غير الآمنة حد مرتبط لكنه منفصل. يخضع تنزيل يبدأ من صفحة آمنة عبر http:// لمعالجة أمن التنزيلات، لا لقواعد الموارد الفرعية هنا.
• التنقل الأعلى عبر HTTP لا يزال غير مختلط، ومنه حالة الرابط السابقة، لأنه تنقل لا مورد فرعي محمّل.

اكتشاف المحتوى المختلط عبر الطبقات كلها

لا يوجد زر واحد يجيب عن كل شيء؛ فالنتيجة النظيفة في طبقة لا تبرئ سائر الطبقات. افحص على حدة المصدر المسترجع، أي مراجع HTML الخام، والحالة المعروضة/وقت التشغيل، أي طلبات المتصفح بعد التحليل وتشغيل البرامج النصية، وجلسات المستخدمين الفعلية خلف موافقة أو تحويل جغرافي أو تسجيل دخول أو وسم خارجي مشروط. رتّب الأدوات من صفحة واحدة إلى الموقع كله:

1. وحدة Chrome DevTools (الحالة المعروضة/وقت التشغيل). افتح صفحة HTTPS والوحدة. يسجل المحتوى النشط المحظور رسالة مثل “Mixed Content: The page … was loaded over HTTPS, but requested an insecure … This request has been blocked; the content must be served over HTTPS.” (ترجمة) «محتوى مختلط: حُمّلت الصفحة عبر HTTPS لكنها طلبت موردًا غير آمن… حُظر الطلب ويجب تقديم المحتوى عبر HTTPS». أما السلبي المحمّل فيظهر تحذيرًا. تجمع لوحة Security أو تبويب Issues النتائج لكل صفحة. الأداة سريعة للتحقق من إصلاح محدد، لكن صياغة الرسالة والتخطيط وأنواع الموارد المحظورة مرتبطة بالمتصفح وإصداره. جرى التأكد من Chrome في 2026-07؛ تحقق من الإصدار الفعلي وتوقع اختلاف Firefox وSafari وEdge.

2. زاحف الموقع (المصدر المسترجع على نطاق واسع). DevTools لكل صفحة، أما الزحف فللموقع كله. يحدد Ahrefs Site Audit وScreaming Frog الصفحات التي تشير إلى موارد فرعية عبر http:// على موقع HTTPS، وهو النهج الواقعي لآلاف العناوين. لكنه يقرأ المصدر؛ لا يثبت اجتياز الزحف نظافة العرض أو الجلسات الحقيقية. سجّل المتصفح أو الأداة والإصدار بدل نتيجة نجاح/فشل غير مقيدة.

3. تقارير انتهاكات CSP (جلسات المستخدمين الفعلية). اجعل متصفحات الزوار تبلغك بالمحتوى المختلط لتلتقط الموارد المشروطة بصفحة أو مستخدم أو موافقة أو وسم خارجي. تقول web.dev: “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” (ترجمة) «يمكن استخدام سياسة أمان المحتوى لجمع تقارير المحتوى المختلط؛ فعّل ذلك بإضافة Content-Security-Policy-Report-Only كترويسة استجابة». يبلغ وضع Report-Only عن الانتهاكات بلا فرض، لتقيس المشكلة قبل الحظر. استخدم report-to / Reporting-Endpoints الحديث أو report-uri الأقدم. وهذه سياسة تقرير عامة مختلفة عن وضع upgrade-insecure-requests نفسه في report-only، الذي لا يعمل.

استخدم الأدوات الثلاث: DevTools للتحقق من الصفحة المعروضة، والزاحف لجرد المصدر، وتقارير CSP لذيل الحالات التي تظهر في الجلسات الحقيقية. اجتياز زحف واحد دليل على المصدر، لا ضمان لنظافة كل حالة موافقة أو متغير إعلاني أو تخصيص أو عامل.

الإصلاح من المصدر

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

• عناوين HTTPS المطلقة — غيّر http://cdn.example.com/app.js إلى https://cdn.example.com/app.js. هذا أوضح خيار حين لا تثق بسياق التقديم.
• المسارات النسبية إلى الجذر أو الموضع — للموارد التي تملكها على الموقع نفسه، يرث /assets/app.js مخطط الصفحة. تقول إرشادات Google: “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” (ترجمة) «تأكد من ألا تعتمد عناوين الموقع الداخلية والخارجية على بروتوكول محدد؛ استخدم مسارات نسبية أو احذف البروتوكول كما في //example.com/something.js». هذه توصية مشروطة: تحقق من ملكية المورد، ومن سلوك عنوان الأساس الحقيقي لأن <base> أو الوكيل أو سياق AMP قد يغيّر المعنى، ومن أن الشيفرة اللاحقة لا تعيد إنشاء http:// من window.location أو قيمة مطلقة مخزنة.
• العناوين النسبية إلى البروتوكول (//example.com/something.js) تعمل، لكنها ليست الحل العام المفضل. أخضعها لفحوص الملكية وعنوان الأساس؛ يكون https:// الصريح أوضح عادة ويجنب المفاجآت خارج سياق HTTP.

على نطاق واسع لن تعدل القوالب يدويًا، لكن لا تشغل استبدالًا غير محمي على قاعدة الإنتاج. يبدو تحويل http://yourdomain → https://yourdomain بسيطًا وآمنًا غالبًا في النص العادي، لكن محتوى CMS قد يكون مسلسلًا أو منظمًا، مثل مصفوفات PHP وكتل JSON وبيانات محرر الكتل، فيفسده استبدال ساذج. استخدم أداة تفهم تنسيق التسلسل، وانسخ القاعدة احتياطيًا أولًا، ونفّذ تشغيلًا تجريبيًا لمراجعة الصفوف قبل الالتزام. ثم أصلح ملفات القالب والإعداد التي تولد العناوين، ودع الزاحف وتقارير CSP تلتقط البقايا.

upgrade-insecure-requests: شبكة الأمان وحدودها

شبكة الأمان الاستباقية هي توجيه في Content-Security-Policy. تقول web.dev: “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” (ترجمة) «يوجّه upgrade-insecure-requests المتصفح إلى ترقية العناوين غير الآمنة قبل تنفيذ طلبات الشبكة». اضبط الترويسة:

Content-Security-Policy: upgrade-insecure-requests

وفق MDN، فإن التوجيه “instructs user agents to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” (ترجمة) «يوجه وكلاء المستخدم إلى معاملة جميع عناوين الموقع غير الآمنة كما لو استُبدلت بعناوين آمنة». ويشمل “requests to load resources (such as images, scripts, or fonts),” (ترجمة) «طلبات تحميل الموارد، مثل الصور والبرامج النصية والخطوط»، و*“navigation requests (such as link targets) which are same-origin with the document,”* (ترجمة) «طلبات التنقل، مثل أهداف الروابط، التي تشترك مع المستند في الأصل»، و*“navigation requests in nested browsing contexts, such as iframes,”* (ترجمة) «طلبات التنقل في سياقات تصفح متداخلة مثل الإطارات»، و*“form submissions.”* (ترجمة) «عمليات إرسال النماذج». Evidence for this claim The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Scope: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Confidence: high · Verified: 2026-07-14 MDN: CSP upgrade-insecure-requests

هناك تفصيلان تشغيليان. أولًا، ترقية الموارد الفرعية ليست محصورة في الأصل نفسه؛ القيد خاص بترقية التنقل، أما الموارد العادية فتُعاد كتابتها عبر الأصول أيضًا، مثل برنامج من CDN أو خط خارجي. ثانيًا، تحدث إعادة الكتابة قبل تقييم فحوص المحتوى المختلط وCSP، لذلك قد يحمّل مورد كان سيُحظر بعد ترقيته بنجاح؛ فالترقية تسبق الحظر.

ثلاثة حدود لا يجوز إخفاؤها:

• لا يرقّي التنقل الأعلى إلى طرف خارجي. تقول MDN: “However, top-level navigation requests whose target is a different origin will not be upgraded.” (ترجمة) «لن تُرقّى طلبات التنقل في المستوى الأعلى إذا كان هدفها أصلًا مختلفًا». لذلك لا يحل محل HSTS: “The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (ترجمة) «لا يضمن التوجيه ترقية زيارة المستخدم عبر روابط خارجية إلى HTTPS في التنقل الأعلى، ولذلك لا يستبدل ترويسة Strict-Transport-Security (HSTS)».
• هو شبكة لا إصلاح، ولا يرجع إلى HTTP. إذا لم يتوفر المورد عبر HTTPS يفشل الطلب المرقّى، ولا يعود إلى http://. أصلح المصدر، واستخدم التوجيه لما فاتك.
• وضع report-only لا ينفذ الترقية. يُتجاهل upgrade-insecure-requests داخل Content-Security-Policy-Report-Only: لا إعادة كتابة ولا تقرير. استخدم سياسة report-only عامة منفصلة تبلغ عن وجهات http:// المحظورة، مثل default-src https:، لقياس الأثر قبل الفرض.

block-all-mixed-content: توجيه تاريخي في الغالب

يوجد التوجيه المصاحب block-all-mixed-content الذي تقول MDN إنه “prevents loading any assets over HTTP when the page uses HTTPS,” (ترجمة) «يمنع تحميل أي أصول عبر HTTP عندما تستخدم الصفحة HTTPS»، ويشمل “both blockable and upgradable mixed content” (ترجمة) «المحتوى المختلط القابل للحظر والقابل للترقية معًا» والإطارات. لكنه استُبدل عمليًا؛ تصفه MDN بأنه مهمل و*“obsolete in the specification”* (ترجمة) «متقادم في المواصفة»، لأن “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” (ترجمة) «المحتوى الذي لا يُحظر يُرقّى دائمًا الآن إلى اتصال آمن، لذلك لا حاجة إلى التوجيه». استخدم upgrade-insecure-requests واعتبر الآخر إرثًا قد تجده، لا خيارًا جديدًا. وإذا أرسلت UIR فلن يبقى لـblock-all-mixed-content عمل على الطلبات المرقّاة لأن إعادة الكتابة تسبقه.

لماذا يعيد نظام إدارة المحتوى المشكلة؟

المحتوى المختلط ليس تنظيفًا لمرة واحدة؛ فهو يتكرر لأن أنظمة عدة تعيد حقن عناوين http:// بصمت:

• قاعدة بيانات المحتوى. يلصق المحررون في WordPress وDrupal ومعظم أنظمة CMS صورًا وتضمينات بعناوين http:// مطلقة داخل النص. توجد في القاعدة لا القالب، فلا يصل إليها إصلاح الشيفرة؛ وهنا يلزم البحث والاستبدال المدرك للبنية.
• القوالب والإضافات. يعيد عنوان أصل ثابت عبر http:// المشكلة في كل صفحة، وقد تعيدها ترقية إضافة بعد التنظيف.
• الإعلانات والتحليلات ووسوم الأطراف الخارجية. تحمّل مدراء الوسوم والشبكات الإعلانية والدردشة مقتنياتها؛ إذا استدعت http:// فهي مشكلة لا تصلحها داخل مستودعك. التقط الذيل بتقارير CSP واضغط على المورد لتقديم HTTPS أو استبدل الوسم أو احذفه. لا يوجد خيار رابع يشغّل النسخة غير الآمنة بأمان.
• عمال الخدمة والذاكرات المؤقتة. قد يحتفظ العامل باستجابة أو طلب يشير إلى http:// ويعيده بعد إصلاح المصدر. اختبر في جلسة خاصة بلا ذاكرة مؤقتة، وارفع إصدار العامل/الذاكرة عند تغيير العناوين لطرد الإدخالات القديمة.
• عناوين http:// الثابتة في المحتوى القديم وقوالب البريد والطباعة التي يعاد استخدامها.

الخلاصة التشغيلية: اجعل الكشف جزءًا من تدقيق دوري، زاحفًا مع تقارير CSP، لا قائمة تطبق مرة يوم الإطلاق.

علاقة المحتوى المختلط بـHSTS

يحل المحتوى المختلط وHSTS مشكلتين متجاورتين لكن مختلفتين، وخلطهما خطأ شائع:

• يصلح upgrade-insecure-requests الموارد الفرعية التي تطلبها صفحتك الآمنة؛ فيرقّي الصور والبرامج النصية والإطارات.
• يفرض HSTS (Strict-Transport-Security) HTTPS على التنقل الأعلى إلى موقعك حتى في أول طلب وقبل أي تحويل، ويحمي من SSL stripping. وتعرضه Google وسيلة “avoid the cost of the 301 redirect” (ترجمة) «لتجنب كلفة تحويل 301» و*“defeat attacks like SSL Stripping”* (ترجمة) «لهزيمة هجمات مثل تجريد SSL».

لا يستبدل أحدهما الآخر. توضح MDN أن upgrade-insecure-requests “will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (ترجمة) «لا يضمن ترقية تنقل المستخدم الأعلى عند القدوم من روابط خارجية، لذلك لا يحل محل HSTS». يستخدم الإعداد المحكم الاثنين: عناوين مصدر نظيفة أو upgrade-insecure-requests كي لا تحمل الصفحة الآمنة موارد غير آمنة، وHSTS لمنع الوصول إلى الموقع عبر HTTP. ويظل تحذير 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 مع أخطاء تحقق من الشهادة»، كما أن التحميل المسبق قريب من باب باتجاه واحد.

هل يضر المحتوى المختلط بتحسين محركات البحث مباشرة؟

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

آثار SEO حقيقية لكنها مشروطة وليست مباشرة أو مضمونة. لا تثبت إرشادات Google الحالية أن إصلاح المحتوى المختلط يرفع الترتيب مباشرة؛ فإشارة HTTPS مرتبطة بمخطط عنوان الصفحة، أي بدء URL بـhttps://، لا بفحص نظافة الموارد الفرعية، ولذلك لا تلغي صورة واحدة غير آمنة «إشارة HTTPS» وحدها. لكن تظهر آثار لاحقة بحسب العطل: إذا عرض Googlebot صفحة حُظر CSS أو JS فيها فقد يفهرس نسخة ناقصة؛ وقد يضر مؤشر الأمان المخفض بالثقة والتفاعل والتحويل من دون تغير ترتيب؛ كما أن تفضيل Google للعناوين الأساسية عبر HTTPS مشروط بصلاحية الشهادة والتبعيات والتحويلات والإشارات الأساسية المتعارضة. تحقق من العرض والفهرسة والتوحيد القياسي والتحليلات على صفحاتك، ولا تعد بنتيجة عامة، وأصلح المشكلة للأمن والوظيفة أولًا.

يندرج هذا ضمن موضوع HTTPS لتحسين محركات البحث الأوسع، الذي يغطي خطة الترحيل ووزن إشارة الترتيب وHSTS. وإذا كنت تشخص الشهادة نفسها، مثل أخطاء السلسلة والانتهاء وDV/OV/EV، فذلك دليل شقيق.

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

خلاصة مكثفة للنسخة المتقدمة:

• المحتوى المختلط = صفحة HTTPS تحمّل موردًا فرعيًا عبر HTTP. يتعلق بما تحمّله الصفحة لا بروابطها؛ فالرابط أو التنقل الأعلى إلى HTTP ليس محتوى مختلطًا، والتنزيل غير الآمن حد منفصل.
• التصنيف الحالي قابل للترقية/قابل للحظر؛ والنشط/السلبي إطار أقدم مفيد لحجم الضرر. يُحظر النشط، مثل البرامج النصية وأوراق الأنماط والإطارات وXMLHttpRequest/fetch، لأنه قد يعيد كتابة الصفحة؛ فأصلحه أولًا. أما الصور والصوت والفيديو فكانت تخفض مؤشر القفل وتزداد ترقيتها أو حظرها. صور CORS تفشل بدل الترقية، ومرشحات srcset/<picture> قابلة للحظر خلاف img src العادي، وعناوين IP تُحظر، وللسياقات المتداخلة والعمال والأصول المحلية تفاصيل خاصة.
• اكشف عبر ثلاث طبقات: المصدر المسترجع بزاحف مثل Ahrefs Site Audit أو Screaming Frog، والحالة المعروضة بوحدة Chrome DevTools ولوحة Security، مع ملاحظة أن الصياغة مرتبطة بالإصدار وقد تحققت في Chrome بتاريخ 2026-07، وجلسات المستخدمين الفعلية بتقارير Content-Security-Policy-Report-Only. نظافة طبقة لا تبرئ البقية.
• أصلح المصدر بعد التحقق من عمل نظير HTTPS: وجّه كل مورد إلى https://. لا تستخدم المسارات النسبية أو النسبية للبروتوكول قبل التحقق من الملكية وعنوان الأساس. انسخ قاعدة البيانات احتياطيًا واختبر الاستبدال لأن النص الساذج قد يفسد بيانات CMS المسلسلة، وراقب عمال الخدمة والذاكرات التي تعيد مراجع http://.
• يعيد upgrade-insecure-requests كتابة الموارد المشمولة، حتى العابرة للأصول، إلى https:// قبل الإرسال والفحوص. لا رجوع إلى HTTP عند الفشل، ولا ترقية لتنقل خارجي أعلى، لذلك لا يحل محل HSTS. ووضعه نفسه في report-only لا يعمل؛ استخدم سياسة تقرير منفصلة.
• block-all-mixed-content مهمل ومتقادم، ويصبح زائدًا بعد upgrade-insecure-requests لأن الترقية تسبقه.
• المشكلة تتكرر عبر قاعدة CMS والقوالب والإضافات والعمال والذاكرات ووسوم الإعلانات والتحليلات؛ دقق دوريًا.
• أثر SEO مشروط لا مباشر: لا تثبت Google مكسب ترتيب مباشرًا، وإشارة HTTPS مرتبطة بالمخطط. لكن الموارد النشطة المحظورة قد تجعل Googlebot يعرض ويفهرس صفحة مكسورة، وخفض القفل يضر الثقة، وتفضيل العنوان الأساسي HTTPS نفسه مشروط بصلاحية الشهادة وتوافق الإشارات.

الوثائق الرسمية

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

Google / web.dev

• ما المحتوى المختلط؟ — التعريف وتقسيم النشط والسلبي وسلوك المتصفح.
• إصلاح المحتوى المختلط — الكشف وإصلاح عناوين الموارد وupgrade-insecure-requests وتقارير CSP.
• تفعيل HTTPS على خوادمك — العناوين النسبية والنسبية للبروتوكول، وملاحظة <iframe> عبر HTTP، وإرشادات HSTS.
• منع المحتوى المختلط جزء من إرشادات Google لـHTTPS — خطة نقل الموقع والترحيل المحيطة بهذه الإصلاحات.

MDN / المعايير

• CSP: upgrade-insecure-requests — ما يرقّيه وما لا يرقّيه ولماذا لا يستبدل HSTS.
• CSP: block-all-mixed-content — توجيه الحظر المهمل والمتقادم.
• MDN — المحتوى المختلط — مرجع سلوك المتصفح للمحتوى القابل للحظر والترقية.
• سياسة أمان المحتوى (CSP) — الترويسة التي تضم التوجيهات والتقارير.

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

تعريفات موثقة من web.dev التابعة لـGoogle ووثائق معايير MDN. ينقلك كل رابط إلى المقطع المقتبس حين تدعم المنصة ذلك.

Google / web.dev — تعريف المحتوى المختلط

• “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (ترجمة) «تحتوي الصفحة على محتوى مختلط عندما يُحمّل HTML الأولي عبر HTTPS آمن، بينما تُحمّل موارد أخرى عبر HTTP غير آمن». المصدر
• “Active mixed content poses a greater threat than passive mixed content.” (ترجمة) «يشكل المحتوى المختلط النشط تهديدًا أكبر من السلبي». المصدر
• المحتوى النشط “includes scripts, stylesheets, iframes, and any other code the browser can download and execute,” (ترجمة) «يشمل البرامج النصية وأوراق الأنماط والإطارات وأي شيفرة ينزلها المتصفح وينفذها»، و*“Most browsers already block this type of content by default to protect users.”* (ترجمة) «تحظر معظم المتصفحات هذا النوع افتراضيًا لحماية المستخدمين». المصدر
• المحتوى السلبي “including images, video, and audio,” (ترجمة) «يشمل الصور والفيديو والصوت»، و*“doesn’t interact with the rest of the page.”* (ترجمة) «لا يتفاعل مع بقية الصفحة». وتضيف: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” (ترجمة) «حتى وقت قريب كان يُحمّل في جميع المتصفحات لأن حظره كان سيعطل مواقع كثيرة، وهذا يتغير الآن». المصدر

Google / web.dev — الكشف والإصلاح

• “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” (ترجمة) «يمكن استخدام سياسة أمان المحتوى لجمع تقارير المحتوى المختلط، وذلك بإضافة Content-Security-Policy-Report-Only كترويسة استجابة». المصدر
• “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” (ترجمة) «يوجه upgrade-insecure-requests المتصفح إلى ترقية العناوين غير الآمنة قبل طلب الشبكة». المصدر
• “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” (ترجمة) «تأكد من ألا تعتمد العناوين الداخلية والخارجية على بروتوكول محدد؛ استخدم مسارات نسبية أو احذف البروتوكول كما في //example.com/something.js». المصدر

MDN — upgrade-insecure-requests وحدوده

• “The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive instructs user agents to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” (ترجمة) «يوجه التوجيه وكلاء المستخدم إلى معاملة كل عناوين الموقع غير الآمنة كما لو استُبدلت بعناوين آمنة». المصدر
• “However, top-level navigation requests whose target is a different origin will not be upgraded.” (ترجمة) «لكن طلبات التنقل الأعلى التي تستهدف أصلًا مختلفًا لن تُرقّى». المصدر
• “The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (ترجمة) «لا يضمن التوجيه ترقية التنقل الأعلى للزوار القادمين من روابط خارجية، ولذلك لا يستبدل HSTS». المصدر

MDN — block-all-mixed-content توجيه قديم

• “The HTTP Content-Security-Policy (CSP) block-all-mixed-content directive prevents loading any assets over HTTP when the page uses HTTPS.” (ترجمة) «يمنع التوجيه تحميل أي أصول عبر HTTP عندما تستخدم الصفحة HTTPS». لكنه موسوم deprecated (ترجمة) «مهمل»، و*“obsolete in the specification,”* (ترجمة) «متقادم في المواصفة»، لأن “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” (ترجمة) «المحتوى غير المحظور يُرقّى دائمًا الآن إلى اتصال آمن، فلا حاجة إلى التوجيه». المصدر

قائمة فحص المحتوى المختلط

نفّذها أثناء الترحيل من HTTP إلى HTTPS وبعده، ثم بصورة دورية:

اكتشفه

• حمّلت القوالب الأساسية، مثل الرئيسية والمنتج والمقال والدفع، عبر HTTPS مع فتح وحدة Chrome DevTools وسجلت كل رسالة “Mixed Content”.
• نفذت زحفًا كاملًا عبر Ahrefs Site Audit أو Screaming Frog واستخرجت الصفحات التي تشير إلى موارد http://.
• ضبطت Content-Security-Policy-Report-Only مع نقطة تقارير لالتقاط حالات الإنتاج بحسب المستخدم والصفحة والوسم الخارجي.

أصلحه، وابدأ بالنشط

• أصلحت كل المراجع النشطة: <script> و<link rel="stylesheet"> و<iframe> وfetch/XMLHttpRequest والخطوط؛ فهي محظورة وتكسر الصفحة.
• أصلحت كل المراجع السلبية: <img> و<audio> و<video> وعناوين <source>/poster.
• نفذت استبدال قاعدة CMS من http://yourdomain إلى https://yourdomain للمحتوى الملصق بعد النسخ الاحتياطي والتشغيل التجريبي بأداة تدرك البنية، لا باستبدال خام على حقول مسلسلة.
• أصلحت عناوين http:// الثابتة في القالب والإضافات.
• أعدت إنتاج إدخالات عامل الخدمة/الذاكرة المؤقتة في جلسة بلا ذاكرة، ورفعت الإصدار لمنع إعادة المراجع القديمة.
• تأكدت من تحميل وسوم الأطراف الخارجية، مثل الإعلانات والتحليلات والدردشة والتضمينات، عبر HTTPS أو دفعت المورد للإصلاح أو حذفت الوسم.

أضف شبكة أمان وتحقق

• ضبطت ترويسة Content-Security-Policy: upgrade-insecure-requests كشبكة أمان مع فهم أنها لا تستبدل HSTS.
• أعدت الزحف وفحص الوحدة: صفر موارد نشطة محظورة ومؤشر أمان نظيف في الصفحات المفحوصة.
• أضفت كشف المحتوى المختلط إلى التدقيق الدوري، لا قائمة الإطلاق وحدها، لأن التحديثات والمحتوى الجديد يعيدان المشكلة.

أي إصلاح تحتاجه حالة المحتوى المختلط هذه؟

اتبع المسار بدءًا من العَرَض.

هل الشيء غير الآمن مورد تحمّله الصفحة أم رابطًا تحتويه؟

• الرابط (<a href="http://…">) ليس محتوى مختلطًا. اتركه، أو وجّهه اختياريًا إلى HTTPS لنظافة بيانات الإحالة، وتوقف هنا.
• المورد المحمّل، مثل برنامج أو نمط أو إطار أو صورة أو خط أو وسيط أو fetch، تابع تشخيصه.

هل المورد متاح عبر HTTPS؟

• نعم، وقد تحققت من الشهادة والمحتوى: غيّر المرجع إلى https://، وهو الافتراضي الآمن، أو إلى مسار نسبي/نسبي للبروتوكول فقط إذا ملكت المورد وفحصت عنوان الأساس. هذا هو الإصلاح.
• لا أو غير متأكد: هل المورد من طرفك؟
  • من طرفك: قدّمه عبر HTTPS ثم أصلح المرجع.
  • خارجي: اطلب نقطة HTTPS من المورد؛ إن لم توجد فاستبدل الوسم أو احذفه. سيحاول upgrade-insecure-requests ترقيته، لكنه يفشل إذا لم توجد نسخة HTTPS.

هل هو نشط أم سلبي؟

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

هل تريد شبكة أمان لما فاتك؟

• اضبط Content-Security-Policy: upgrade-insecure-requests. تذكر أنه شبكة لا بديل، ولا يغطي التنقل الأعلى الخارجي، لذلك لا يقوم مقام HSTS.

هل تريد أيضًا فرض HTTPS على الصفحة العليا في الزيارة الأولى أو الإحالة الخارجية؟

• هذه مهمة HSTS المنفصلة. أضف Strict-Transport-Security فقط حين تصبح عملية الشهادات متينة؛ فـHSTS، وخصوصًا preload، قريب من باب باتجاه واحد.

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

1. الموارد لا الروابط. يتعلق المحتوى المختلط بما تحمّله الصفحة الآمنة، لا بما ترتبط به. اسأل: هل يجلب المتصفح هذا لبناء الصفحة الحالية؟ نعم تعني احتمال المحتوى المختلط، أما الانتقال إلى صفحة أخرى فلا.

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

3. الكشف قمع: تحقق ← اجرد ← التقط الذيل. وحدة DevTools لصفحة بدقة، والزاحف للموقع كله، وتقارير CSP للإنتاج والوسوم الخارجية والحالات الفردية. لا ترى أداة واحدة الطبقات الثلاث.

4. أصلح المصدر ثم ضع شبكة للباقي. نظف العناوين الفعلية في القاعدة والقوالب والوسوم، ثم أضف upgrade-insecure-requests لما يتسرب. التوجيه تأمين لا إصلاح.

5. مهمتان مختلفتان لفرض HTTPS وأداتان مختلفتان. يرقّي upgrade-insecure-requests الموارد الفرعية التي تطلبها الصفحة الآمنة. ويفرض HSTS HTTPS على التنقل الأعلى إلى موقعك. لا يستبدل أحدهما الآخر؛ الموقع المحكم يستخدم الاثنين.

6. تدقيق دوري لا مهمة لمرة واحدة. تعيد قاعدة CMS وتحديثات الإضافات والقوالب والوسوم الخارجية http://. اجعل الكشف فحصًا مجدولًا وإلا عادت المشكلة بصمت.

أنماط خاطئة في معالجة المحتوى المختلط

أخطاء تُبقي المحتوى غير الآمن حيًا أو تخفيه بدل إصلاحه.

• اعتبار upgrade-insecure-requests إصلاحًا. هو شبكة؛ يفشل المورد الذي لا يملك HTTPS، فتخفي تبعية مكسورة. نظف المصدر واستخدم التوجيه للذيل.
• افتراض أن نشر الشيفرة نظف القاعدة. معظم صور وتضمينات http:// في CMS موجودة في صفوف المحتوى لا القوالب. نفذ استبدال القاعدة الآمن.
• خفض أولوية النشط لأنه «مجرد تحذير». النشط محظور، وورقة الأنماط أو البرنامج المحظور عطل وظيفي.
• فحص الرئيسية فقط. تختبئ المشكلة في المنتجات والمقالات القديمة والمسارات النادرة. ازحف الموقع واستخدم تقارير CSP.
• تجاهل الوسوم الخارجية. وسم إعلان أو تحليل أو دردشة يستدعي http:// لا يصلحه مستودعك؛ اضغط على المورد أو احذف الوسم.
• استخدام block-all-mixed-content في بناء جديد. هو مهمل ومتقادم؛ استخدم upgrade-insecure-requests.
• خلط upgrade-insecure-requests بـHSTS. الأول يرقّي الموارد الفرعية، والثاني يفرض HTTPS الأعلى ويحمي من SSL stripping؛ نشر أحدهما لا يغطي الآخر.
• إسقاط الكشف من التدقيق الدوري. سيعيد تحديث إضافة أو صورة ملصقة عبر http:// المشكلة بلا ملاحظة.

ورقة مرجعية للمحتوى المختلط

النشط مقابل السلبي

طبقات الكشف

توجيهات CSP

لا تخلط بينهما

إصلاح بسطر واحد في CMS: ابحث في القاعدة واستبدل http://yourdomain بـhttps://yourdomain، ثم أصلح القوالب والإضافات، واضبط upgrade-insecure-requests.

مقتطفات لاكتشاف المحتوى المختلط

1. ازحف صفحة واحدة من سطر الأوامر

اجلب الصفحة وحدد موارد src/href الفرعية غير الآمنة الباقية في HTML.

macOS / Linux

# Flag insecure script/img/link/iframe/source references on a single URL
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

لا يرى هذا سوى HTML الخام؛ لن تظهر الموارد التي يحقنها JavaScript، ولهذا تحتاج أيضًا إلى DevTools وزاحف حقيقي.

2. وحدة Chrome DevTools — اسرد الموارد غير الآمنة في الصفحة المعروضة

الصق المقتطف في وحدة صفحة HTTPS لالتقاط المراجع التي يحقنها JS أيضًا:

// Every element with an http:// resource attribute in the live DOM
[...document.querySelectorAll('[src],[href],[srcset],[data-src]')]
  .filter(el => /^http:\/\//.test(
    el.src || el.href || el.getAttribute('srcset') || el.getAttribute('data-src') || ''
  ))
  .map(el => ({ tag: el.tagName, url: el.src || el.href }));

يسجل المتصفح أيضًا المحتوى المختلط النشط المحظور تلقائيًا بهذه الصياغة تقريبًا: “Mixed Content: … This request has been blocked; the content must be served over HTTPS.” (ترجمة) «محتوى مختلط: حُظر هذا الطلب؛ ويجب تقديم المحتوى عبر HTTPS». اقرأ هذه الرسائل أولًا.

3. Bookmarklet — تفريغ الوحدة بنقرة

احفظه إشارة مرجعية، ثم انقره في أي صفحة HTTPS ليطبع مراجع http:// في الوحدة:

javascript:(()=>{const h=[...document.querySelectorAll('[src],[href]')].filter(e=>/^http:\/\//.test(e.src||e.href)).map(e=>e.src||e.href);console.log('%cMixed content candidates:','font-weight:bold',h.length);h.forEach(u=>console.log(u));})();

4. فعّل تقارير CSP للكشف في الإنتاج

أضف ترويسة report-only كي تبلغك متصفحات الزوار الفعليين بالانتهاكات، ومنها الوسوم الخارجية والصفحات التي يفوتها الزحف:

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-report-endpoint

يُصدر report-only تقارير من دون فرض، فتقيس حجم المشكلة بأمان قبل تفعيل upgrade-insecure-requests أو الفرض. يستخدم النظير الحديث report-to مع ترويسة Reporting-Endpoints.

5. ترويسة شبكة الأمان بعد إصلاح المصدر

Content-Security-Policy: upgrade-insecure-requests

تذكر أنها لا ترقّي التنقل الأعلى إلى أصل خارجي، وأنها ليست بديلًا عن HSTS.

إجراء تشغيلي معياري لتدقيق المحتوى المختلط دوريًا

نفّذه بعد إطلاق HTTPS وإصدارات CMS أو القالب وتغييرات مدير الوسوم، وبجدول دوري للمواقع سريعة التغير.

1. ازحف صفحات HTTPS بالوضعين الخام والمعروض. صدّر العناوين غير الآمنة من src وsrcset وأوراق الأنماط والإطارات والوسائط وطلبات fetch/XHR؛ روابط HTTP العادية ليست محتوى مختلطًا.
2. اجمع أدلة المتصفح. راجع DevTools في قوالب ممثلة، واستخدم Content-Security-Policy-Report-Only لالتقاط انتهاكات الزوار والوسوم الخارجية.
3. صنف كل نتيجة. نشطة أم سلبية، ومن طرفك أم خارجي، وثابتة أم محقونة بـJavaScript، وحدد القالب أو حقل القاعدة أو الإضافة أو الوسم أو المورد المسؤول.
4. أصلح مرجع المصدر. وجّهه إلى مورد HTTPS يعمل أو عنوان نسبي آمن. لا تفترض أن تبديل http:// إلى https:// يكفي؛ تحقق من TLS.
5. استخدم CSP شبكة أمان. أضف upgrade-insecure-requests بعد مراجعة النتائج؛ يقلل التعرض لكنه لا يصلح سجل CMS ولا يستبدل HSTS.
6. أعد الزحف والعرض. يجب أن تصبح أخطاء النشط صفرًا في القوالب المختبرة، وأن تعمل الموارد السلبية عبر HTTPS بلا رجوع.
7. امنع التكرار. أصلح القالب أو سير التحرير المسبب، واحتفظ بالتقارير عند الحاجة، وأسند الانتهاكات الجديدة إلى مالك النظام.

العَرَض ← السبب المحتمل ← الإصلاح

اختبارات إصدار المحتوى المختلط

الاختبار 1: مسح القوالب المعروضة

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

الاختبار 2: مقارنة المصدر بتقارير CSP

• الغرض: كشف الانتهاكات التي تظهر للزوار الفعليين أو تأتي من أطراف خارجية فقط.
• الطريقة: قارن نتائج الزاحف بأحداث Content-Security-Policy-Report-Only مجمعة حسب العنوان المحظور والقالب والتوجيه والمالك.
• النتيجة المتوقعة: لا انتهاكات إنتاج غير مفسرة؛ والضوضاء المعروفة موثقة ومستبعدة بدقة.
• مسبب الفشل: انتهاك قابل للتكرار غائب عن الزحف أو مصدر خارجي بلا مالك.
• الإجراء التالي: أعد حالة الزائر وأصلح التكامل المحقن أو احذفه.

الاختبار 3: اختبار التكرار بعد النشر

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

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

محاضراتي

• الأفضل أن تكون آمنًا لا نادمًا مع HTTPS — SMX East 2016 (SlideShare) — معالجة معمقة لـTLS وأخطاء تطبيق HTTPS ومشكلات الترحيل التي تولد المحتوى المختلط. تنبيه دائم: هذا فهمي للأنظمة وإحصاءات التبني فيه تعود إلى 2016.

كتابات مرتبطة

• دليل المبتدئ إلى تحسين محركات البحث التقني — موضع HTTPS والمحتوى المختلط في الصورة التقنية الأوسع.

من الصناعة

• ما المحتوى المختلط؟ (web.dev / Google) — التعريف المرجعي وتقسيم النشط والسلبي.
• إصلاح المحتوى المختلط (web.dev / Google) — الكشف وإصلاح عناوين الموارد وupgrade-insecure-requests وتقارير CSP خطوة بخطوة.
• MDN — upgrade-insecure-requests — ما يرقّيه وما لا يرقّيه ولماذا لا يحل محل HSTS.
• MDN — block-all-mixed-content — توجيه الحظر المهمل عند وراثته.
• MDN — المحتوى المختلط — مرجع سلوك الموارد القابلة للحظر والترقية.
• تفعيل HTTPS على خوادمك (web.dev / Google) — العناوين النسبية والنسبية للبروتوكول وإرشادات إعداد HTTPS.

إحصاءات وعبارات قابلة للاقتباس

• يُحظر المحتوى النشط افتراضيًا. تقول Google: “Most browsers already block this type of content by default to protect users.” (ترجمة) «تحظر معظم المتصفحات هذا النوع افتراضيًا لحماية المستخدمين»؛ لذلك هو عطل وظيفي لا تحذير. المصدر
• النشط هو التهديد الأكبر. تقول Google: “Active mixed content poses a greater threat than passive mixed content.” (ترجمة) «يشكل النشط تهديدًا أكبر من السلبي»، وهو ما يحدد الأولوية. المصدر
• لم يعد السلبي «مسموحًا» بأمان. تقول Google: “Until recently, passive mixed content was loaded in all browsers … This is now beginning to change.” (ترجمة) «حتى وقت قريب كان السلبي يُحمّل في كل المتصفحات… وهذا يتغير الآن»؛ لذا ينتهي افتراض أن الصور غير ضارة. المصدر
• upgrade-insecure-requests لا يستبدل HSTS. تقول MDN إنه “does not replace the Strict-Transport-Security (HSTS) header.” (ترجمة) «لا يستبدل ترويسة HSTS»؛ فالأداتان تحلان نصفين مختلفين. المصدر
• نحو 89 % من الويب يستخدم HTTPS وفق W3Techs في 2026؛ تحقق من الرقم الحالي. لذلك تعد موارد http:// المتبقية داخل صفحة آمنة نمط فشل شائعًا: الصفحة HTTPS لكن حمولتها متأخرة. راجع دليل HTTPS.

اختبر نفسك: المحتوى المختلط

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

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