رفع و پیشگیری از خطای mixed content در سایت‌های HTTPS

وقتی یک صفحهٔ بارگذاری‌شده از طریق HTTPS منابعی را با آدرس HTTP بارگذاری کند، مرورگرها این وضعیت را به‌عنوان خطای mixed content شناسایی می‌کنند. این وضعیت به معنی وارد کردن منابع ناایمن (مثل اسکریپت، استایل، تصویر، فونت یا iframe) در صفحهٔ امن است که مزایای رمزنگاری و یکپارچگی اتصال را تضعیف می‌کند. پیامدهای متداول عبارتند از کاهش امتیاز امنیتی، بلاک شدن بخش‌هایی از صفحه و مشکلات سئو/کارایی.

انواع فنی

• Active mixed content: منابعی که می‌توانند رفتار یا ساختار صفحه را تغییر دهند، مانند اسکریپت‌ها، درخواست‌های AJAX/Fetch و iframes؛ مرورگرها معمولاً این منابع را بلاک می‌کنند.
• Passive mixed content: منابعی که به‌طور مستقیم عملکرد صفحه را تغییر نمی‌دهند مثل تصاویر، ویدیوها، صوت و فونت‌ها؛ ممکن است بارگذاری شوند اما امنیت را تضعیف می‌کنند و بسته به سیاست مرورگر قابل بلاک یا هشداردهی‌اند.

دلایل متعددی باعث بروز این خطا می‌شوند. شناسایی الگوهای رایج کمک می‌کند راه‌حل مناسب انتخاب شود:

• مسیرهای سخت‌کد شده با پیشوند http:// در HTML، CSS یا JavaScript.
• بارگذاری منابع از سرویس‌های خارجی که TLS را پشتیبانی نمی‌کنند یا گواهی آن‌ها صحیح نیست.
• تولید خودکار لینک‌ها در سیستم‌های مدیریت محتوا یا APIها که هنوز پروتکل امن را لحاظ نمی‌کنند.
• پلاگین‌ها یا بسته‌هایی که آدرس‌های قدیمی را بدون به‌روزرسانی تزریق می‌کنند.
• استفاده از CDN یا پراکسی‌هایی که پیکربندی HTTPS ندارند یا با mixed backend کار می‌کنند.

شناسایی سریع منبع مشکل اولین گام است. ابزارها و روش‌های زیر مفیدند:

1. باز کردن ابزار توسعه‌دهندهٔ مرورگر (DevTools) و مشاهدهٔ تب Console؛ پیام‌های mixed content معمولاً نوع منبع و آدرس را نشان می‌دهند.
2. در تب Network فیلتر درخواست‌ها را فعال کنید و ستون Scheme یا Protocol را بررسی کنید تا درخواست‌های HTTP مشخص شوند.
3. جستجوی متن http:// در کد منبع، فایل‌های CSS/JS و dumpهای دیتابیس با ابزارهای خط فرمان مانند grep یا ابزارهای زبان برنامه‌نویسی.
4. استفاده از دستورهای خط فرمان برای بررسی هدرها و پاسخ سرور؛ مثال عمومی:

   curl -I "https://<your-host>/path"
   

5. اجرای خزنده‌های سایت یا اسکریپت‌های خودکار برای استخراج تمام URLهای خروجی و گزارش منابع با پروتکل HTTP.

پس از شناسایی موارد مشکل‌دار، منابع فعال را در اولویت قرار دهید چون بیشترین ریسک را دارند.

این چک‌لیست را دنبال کنید تا فرآیند رفع منظم، قابل بازگشت و قابل تست باشد:

1. تهیهٔ نسخهٔ پشتیبان: قبل از هر تغییر از فایل‌ها و پایگاه‌داده نسخه تهیه کنید تا در صورت بروز خطا بتوانید بازگردانید.
2. ایجاد فهرست کاملی از URLها: لیست کامل URLهای http:// را از کد، دیتابیس، تنظیمات پلاگین‌ها و فایل‌های استاتیک استخراج کنید.
3. اصلاح لینک‌ها: جایگزینی مستقیم http:// با https:// یا استفاده از مسیرهای نسبی (//host/path یا /path) وقتی مناسب است. مثال:

   <script src="https://cdn.example/library.js"></script>
   

4. میزبانی محلی منابع ضروری: اگر سرویس خارجی HTTPS ندارد، فایل را به سرور امن خود منتقل کنید یا از CDN امن استفاده کنید.
5. پیکربندی ریدایرکت سطح سرور: تنظیم ریدایرکت‌های 301 برای هدایت تمام درخواست‌های HTTP به HTTPS. نمونهٔ کلی برای یک موتور پیکربندی:

   # نمونهٔ منطقی (قالب) برای ریدایرکت
   if request_scheme == 'http' then
     return 301 https://{host}{request_uri}
   end
   

6. تنظیم هدرهای امنیتی و CSP: افزودن directiveهایی مانند upgrade-insecure-requests و/یا block-all-mixed-content در Content-Security-Policy می‌تواند به‌عنوان لایهٔ محافظ کار کند و گزارش‌دهی نیز فعال شود.
7. تست مرحله‌ای: تمام تغییرات را در محیط staging بررسی کنید؛ لاگ‌ها و کنسول مرورگر را برای خطاها پایش کنید و تست‌های کارکردی را اجرا کنید.
8. نظارت پس از انتشار: پس از انتشار، نظارت ۷۲ ساعته روی لاگ‌ها و مانتیورینگ کنسول انجام دهید تا بازگشت مشکل سریع شناسایی شود.

مثال بلوکی از کد که باعث خطای mixed content می‌شود:

<script src="http://cdn.example/library.js"></script>

گزینه‌های اصلاح:

1. استفاده از نسخهٔ HTTPS ارائه‌شده: <script src="https://cdn.example/library.js">
2. بسته‌بندی و میزبانی محلی فایل روی سرور امن و اشاره به مسیر داخلی.
3. راه‌حل پراکسی سرور: لایهٔ سرور URL ناایمن را fetch کرده و آن را از طریق اتصال امن به کاربر ارائه دهد (راه‌حل موقتی و نیازمند کنترل کش و هدرها).

در این بخش نمونه‌های عمومی و نکات برای اعمال در لایهٔ سرور (بدون وابستگی به محصول خاص) آورده شده است:

مثال برای هدایت تمام ترافیک HTTP به HTTPS

# قالب منطقی برای ریدایرکت در سطح سرور
if request_scheme == 'http' then
  return 301 https://{host}{request_uri}
end

نمونه تنظیمات Content-Security-Policy

Content-Security-Policy: default-src 'self' https:; upgrade-insecure-requests; block-all-mixed-content; report-uri https://your-monitoring-endpoint/report

توجه: استفاده از upgrade-insecure-requests مرورگر را وادار می‌کند تلاش کند منابع HTTP را به HTTPS ارتقا دهد؛ این گزینه برای مهاجرت سریع مناسب است اما همیشه اصلاح مستقیم منابع ارجح است.

برای جلوگیری از بازگشت خطاها و سرعت بخشیدن به اصلاح، این روش‌ها را به فرایند توسعه اضافه کنید:

• اسکریپت‌های خط فرمان (مثل grep، ripgrep) برای جستجوی http:// در مخزن و فایل‌های خروجی.
• خزنده‌های سایت که تمام منابع صفحه را فهرست کنند و گزارش منابع ناایمن تولید کنند.
• اضافه کردن چک در پایپلاین CI: هر pull request قبل از ادغام بررسی شده و در صورت وجود آدرس‌های http:// فرایند با شکست مواجه شود.
• ابزارهای مانیتورینگ و لاگ‌گیری برای ضبط رخدادهای mixed content و ارسال هشدار.
• برای رفتار سطح پروتکل و خطاهای HTTP/TLS می‌توانید به اسناد فنی پروتکل‌ها مراجعه کنید: https://datatracker.ietf.org/doc/html/rfc7230

آیا همهٔ mixed contentها فوراً بلاک می‌شوند؟

خیر؛ مرورگرها بسته به نوع منبع و سیاست امنیتی رفتار متفاوتی دارند. منابع فعال معمولاً بلاک می‌شوند در حالی که منابع passive ممکن است فقط هشدار داده شوند یا گاهی بارگذاری شوند اما ریسک امنیتی ایجاد می‌کنند.

آیا استفاده از upgrade-insecure-requests همیشه کافی است؟

این دستورالعمل می‌تواند به مهاجرت سریع کمک کند اما راه‌حل نهایی نیست. بهترین روش اصلاح مستقیم منابع، اطمینان از پشتیبانی HTTPS در سرویس‌ها و به‌روزآوری لینک‌هاست.

چگونه می‌توانم از بازگشت مشکل جلوگیری کنم؟

افزودن چک‌های خودکار در روند انتشار، آموزش تیم برای استفاده صریح از HTTPS، بررسی دوره‌ای دیتابیس و کانفیگ‌ها و مانیتورینگ مداوم از راه‌های اثربخش جلوگیری از بازگشت هستند.