كيفية حل تحذير المحتوى المختلط (Mixed Content)؟

ثبّتّ شهادة SSL على موقعك، لكن القفل في شريط العنوان لا يزال غير ظاهر، أو يعرض "غير آمن" مع علامة تعجب. السبب الأكثر شيوعًا لذلك هو المحتوى المختلط (mixed content): فبينما تُحمَّل الصفحة نفسها عبر HTTPS، لا تزال بعض الموارد بداخلها تُستدعى عبر HTTP. في هذه المقالة، نشرح كيفية إيجاد المشكلة وحلها بشكل دائم.

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

عندما تُحمّل صفحة آمنة (https://) موردًا غير آمن (http://)، يعدّ المتصفح ذلك ثغرة أمنية. وله نوعان:

  • المحتوى المختلط السلبي: موارد مثل الصور والفيديو والصوت. عادةً ما يحمّلها المتصفح لكنه يزيل القفل ويكتب تحذيرًا في الكونسول.
  • المحتوى المختلط النشط: السكريبتات وملفات الأنماط (CSS) وإطارات iframe واستدعاءات XHR/fetch. هذه يحجبها المتصفح لأنها قد تستولي على الصفحة، فيبدو موقعك معطّلاً.

الخطوة 1 — اعثر على الموارد المسبّبة

افتح أدوات المطوّر في المتصفح (F12) وانظر إلى تبويب Console. تُدرج تحذيرات المحتوى المختلط بوضوح:

Mixed Content: The page at 'https://alanadiniz.com/' was loaded over HTTPS,
but requested an insecure resource 'http://alanadiniz.com/img/logo.png'.
This content should also be served over HTTPS.

يخبرك كل سطر بأي مورد حُمّل عبر HTTP. استخرج هذه القائمة لتحديد العناوين التي يجب إصلاحها.

صورة: <تحذيرات المحتوى المختلط في كونسول DevTools>
كونسول أدوات المطوّر يدرج الموارد غير الآمنة واحدًا تلو الآخر.

الخطوة 2 — أصلح عناوين الموارد

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

<!-- خطأ -->
<img src="http://alanadiniz.com/img/logo.png">
<script src="http://cdn.ornek.com/lib.js"></script>

<!-- صحيح -->
<img src="https://alanadiniz.com/img/logo.png">
<img src="/img/logo.png">                  <!-- نسبي للجذر، الأكثر أمانًا -->
<script src="https://cdn.ornek.com/lib.js"></script>

لا تنسَ أيضًا تعريفات url(http://...) داخل ملفات CSS وقيم background-image المضمّنة.

الخطوة 3 — استبدل العناوين القديمة في قاعدة البيانات دفعةً واحدة

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

-- خذ نسخة احتياطية أولاً!
UPDATE icerikler
SET govde = REPLACE(govde, 'http://alanadiniz.com', 'https://alanadiniz.com');

كيّف أسماء الجداول والأعمدة بحسب مخطّطك الخاص.

الخطوة 4 — حل جماعي: upgrade-insecure-requests

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

# Nginx
add_header Content-Security-Policy "upgrade-insecure-requests";
<!-- أو داخل <head> في HTML -->
<meta http-equiv="Content-Security-Policy"
      content="upgrade-insecure-requests">

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

الخطوة 5 — امسح الذاكرة المؤقتة وتحقّق

بعد التغييرات، امسح الذاكرة المؤقتة للمتصفح ولشبكة CDN إن وُجدت، ثم افتح الصفحة في نافذة تصفح خاص وتأكد عبر F12 ← Console من عدم بقاء أي تحذير. إذا عادت أيقونة القفل، فقد حُلّت المشكلة.

المزالق الشائعة

  • العناوين المكتوبة بشكل ثابت (hardcoded): روابط http:// المضمّنة في ملفات القوالب والإضافات.
  • سكريبتات الإعلانات/التحليلات الخارجية: أزل أو حدّث الموارد الخارجية التي لا تدعم HTTPS.
  • أكواد تضمين وسائل التواصل القديمة: استبدلها بأكواد تضمين جديدة متوافقة مع HTTPS.

الخلاصة

ينشأ المحتوى المختلط من موارد HTTP المتبقية في صفحة HTTPS ويُسقط القفل. اعثر على الموارد المسبّبة من الكونسول، واجعل العناوين https://، وادعمها عند الحاجة بـ upgrade-insecure-requests. إذا لم تكن لديك شهادة بعد أو كنت بحاجة إلى تجديدها، فأنشئها عبر معالج SSL المجاني لدينا ونزّل حزمة ZIP.