Defaults.Exposed › الإصلاحات › HTTPS وإعادة التوجيه الإجبارية إلى الاتصال الآمن

كيف تُصلح HTTPS وإعادة التوجيه الإجبارية إلى الاتصال الآمن

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

الخلاصة لعملك: بدون HTTPS، تعبر كل كلمة مرور ورقم بطاقة ورسالة يرسلها العميل إليك الإنترنت كنصّ مقروء، ويختم Chrome وEdge وSafari وFirefox جميعاً موقعك بوسم 'غير آمن' لكل زائر قبل أن يقرأ كلمة. وبدون إعادة التوجيه، تترك حتى المواقع التي تحمل شهادة الزيارة الأولى بلا حماية. كلاهما يكلّفك ثقة ومبيعات وترتيباً في البحث — وكلاهما مجاني الإصلاح في دقائق.

ماذا قد يكلّفك هذا

• يرى زائر لأول مرة تحذيراً كبيراً بـ 'غير آمن' لحظة تحميل صفحتك. يفترض معظمهم أن الموقع مزيّف أو معطوب أو غير آمن فيغادرون إلى منافس — ولا تعرف أبداً أن البيع ضاع.
• يُدخِل عميل تفاصيل بطاقته أو يسجّل الدخول عبر اتصال غير مشفّر من مقهى أو فندق أو مطار. يقرؤها أحدهم على شبكة Wi-Fi نفسها كنصّ صريح، وتُنسَب إليك الرسوم الاحتيالية التي تتبع ذلك.
• يُجري فريق المشتريات أو الأمن لدى عميل أكبر فحصاً سريعاً قبل التوقيع، فلا يجد HTTPS أو يجد إعادة توجيه إجبارية مفقودة، فيُجمّد العقد حتى تثبت أنه أُصلِح.
• ترتّبك Google تحت منافسين يقدّمون HTTPS، فتخسر بهدوء حركة بحث لسنوات دون أن تربط الأمر بهذه الثغرة أبداً.
• تعامل جهة تنظيمية أو مزوّد الدفع لديك إرسال بيانات شخصية أو بيانات بطاقة دون تشفير كإخفاق يجب الإبلاغ عنه، فيتحوّل إصلاح مجاني من خمس دقائق إلى مشكلة امتثال.

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

ما هذا، بكلمات بسيطة

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

هناك جزآن لضبط هذا بشكل صحيح، ونتحقق من كليهما:

• هل HTTPS متاح أصلاً؟ هل يحمل موقعك شهادة أمن عاملة بحيث توجد النسخة الآمنة ذات القفل؟ هذا هو الأخطر من الاثنين — فبدونه لا يوجد تشفير على الإطلاق.
• هل يُجبِر موقعك الزوّار عليه؟ لا أحد تقريباً يكتب “https://” يدوياً. فإذا كتب أحدهم اسم نطاقك فقط، يحاول متصفحه النسخة العادية HTTP أولاً. وتُعيد إعادة التوجيه الإجبارية إلى الاتصال الآمن توجيه ذلك الطلب تلقائياً إلى النسخة المشفّرة. وبدونها، تكون اللحظات الأولى من كل زيارة بلا حماية حتى حين تملك شهادة فعلاً.

أنت تريد كليهما. الشهادة دون إعادة توجيه باب أمامي مقفل يستطيع الزوّار ببساطة الالتفاف حوله.

ما هو على المحكّ تجارياً

هذه أكثر إشارة أساسية على ما إذا كان الموقع آمناً — والأهمّ، إنها إشارة يستطيع عملاؤك رؤيتها بأنفسهم. يُعلِّم كل متصفح حديث (Chrome، Edge، Safari، Firefox) موقعاً بلا HTTPS بـ “غير آمن” في شريط العنوان مباشرة، ويُظهِر تحذيراً إن حاول أحد الكتابة في نموذج. لا يحتاج زوّارك معرفة ما هي الشهادة ليتفاعلوا مع تلك الكلمة.

وبعيداً عن التحذير المرئي، يؤثر هذا في ثلاثة أمور يهتمّ بها المالكون مباشرة: الثقة (يهجر الناس المواقع التي تبدو غير آمنة)، والترتيب في البحث (استخدمت Google منذ سنوات HTTPS كإشارة ترتيب وتفضّل المواقع الآمنة)، والتعرّض الحقيقي (البيانات المرسلة عبر HTTP العادي يمكن فعلاً أن يقرأها آخرون على الشبكة نفسها). وهو أيضاً من الأمور التي يفحصها فريق الأمن لدى عميل أكبر في ثوانٍ أثناء العناية الواجبة — وفقدانه قد يُعطّل صفقة.

ما قد يكلّفك هذا

• المغادرة الصامتة. ينقر عميل محتمل من نتيجة بحث أو إعلان، فتُحمَّل الصفحة بشارة رمادية “غير آمن” — أو أسوأ، تحذير بملء الشاشة. لا يراسلك ليسأل عن السبب؛ بل يُغلق التبويب فحسب وينقر النتيجة التالية. دفعت ثمن تلك الزيارة وخسرتها قبل أن يقرأ كلمة، ولا شيء في تحليلاتك يخبرك بالسبب.
• تسجيل دخول أو دفعة معترَضة. يسجّل عميل الدخول أو يُتمّ الشراء أثناء وجوده على شبكة Wi-Fi مشتركة في فندق أو مقهى. ولأن الاتصال غير مشفّر، يلتقط شخص قريب كلمة مروره أو رقم بطاقته كنصّ صريح. ويُبلَّغ عن الاحتيال الذي يتبع باعتباره اختراقك أنت، وتكون أنت من يتلقّى المكالمات الغاضبة وعمليات ردّ المبالغ.
• الصفقة التي تتعثّر. عميل محتمل أكبر جاهز للتوقيع، لكن عملية مشترياته تتضمن فحصاً أمنياً سريعاً لموقعك. تعود النتيجة مُعلِّمةً غياب HTTPS، أو إعادة توجيه إجبارية مفقودة. وفجأة تشرح ثغرة أمنية أساسية بدلاً من إتمام الصفقة — وينتظر العقد، أو يذهب بهدوء إلى منافس اجتاز الفحص.
• تسرّب الترتيب البطيء. نشاطان تجاريان يقدّمان الشيء نفسه؛ أحدهما يقدّم HTTPS آمناً والآخر لا. ترفع محرّكات البحث الآمن أعلى. وعلى مدى أشهر تخسر تدفّقاً ثابتاً من الحركة المجانية ولا تربطه أبداً بهذا الإعداد الواحد.
• محتوى محقون لم تكتبه أبداً. على اتصال غير مشفّر، يستطيع أي شخص في المنتصف — شبكة عامة مشبوهة، موجّه مخترَق — إدراج نوافذ منبثقة مزيّفة أو عروض احتيال أو برمجيات خبيثة في صفحاتك أثناء تحميل الزائر لها. وبالنسبة لذلك الزائر، يبدو أن موقعك أنت من فعل ذلك.

ما هو فعلاً

حين يتصل متصفح بموقع عبر HTTPS، يحدث أمران. أولاً، يقدّم الموقع شهادة — اعتماداً تُصدِره جهة موثوقة يثبت أن الموقع هو من يدّعي أنه هو. وثانياً، يتفق المتصفح والخادم على مفتاح تشفير ويستخدمانه لتشويش كل ما يتبادلانه. وفحصنا الأول، HTTPS متاح، يسأل ببساطة: هل يمكننا إجراء اتصال TLS آمن بموقعك على المنفذ الآمن القياسي (443) واستعادة شهادة صالحة؟ إن كان نعم، فيمكن أن يظهر القفل والتشفير فعّال. وإن كان لا، فلا توجد نسخة آمنة من موقعك على الإطلاق — وهذا أثقل إخفاق منفرد نقيّمه.

أمّا الفحص الثاني، إعادة التوجيه الإجبارية إلى الاتصال الآمن، فيغطّي ثغرة تتركها الشهادة وحدها مفتوحة. يكتب الناس “yourbusiness.com”، لا “https://yourbusiness.com”. وذلك الطلب المجرّد يذهب إلى نسخة HTTP العادية أولاً. وإعادة التوجيه تعليمة من سطر واحد تقول “أرسِل أي شخص يصل إلى النسخة غير الآمنة مباشرة إلى الآمنة.” وفحصنا يسأل: حين نطلب عنوان HTTP العادي الخاص بك، هل يُعيد موقعك توجيهنا إلى HTTPS؟ إن فعل، فإن كل زائر ينتهي به الأمر محمياً مهما كتب عنوانك. وإن لم يفعل، فإن تلك القفزة الأولى غير المحمية تحمل ما يرسله المتصفح — ملفات تعريف الارتباط، بيانات النماذج — بشكل صريح.

كيف يبدو “الجيد”: شهادة صالحة موثوقة بحيث يظهر القفل على كل صفحة، و كل طلب HTTP عادي يُعاد توجيهه تلقائياً إلى نسخة HTTPS (نموذجياً بإعادة توجيه دائمة “301”، التي تنقل أيضاً ترتيبك في البحث بنظافة إلى العنوان الآمن).

كيفية الإصلاح (مجاناً، ~15 دقيقة)

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

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

1. احصل على شهادة ليعمل HTTPS (القفل).

• Cloudflare: إذا كان موقعك خلف Cloudflare، فإن SSL يُتولّى لك. اضبط وضع SSL/TLS على “Full” (أو “Full (strict)” إن كان خادمك الأصلي يحمل أيضاً شهادة).
• منشئو المواقع والاستضافة المُدارة (Squarespace، Wix، Shopify، Webflow، GoDaddy Website Builder، معظم استضافة ويب Microsoft 365 / Google Workspace): يُقدَّم HTTPS تلقائياً؛ فقط تأكد من تفعيله في إعدادات موقعك/نطاقك — لا شيء لتثبيته عادة.
• استضافة cPanel: افتح SSL/TLS Status وشغّل AutoSSL، الذي يُصدِر شهادة Let’s Encrypt مجانية.
• خادمك الخاص (VPS): ثبّت Let’s Encrypt بـ Certbot — sudo certbot --nginx -d yourdomain.com (أو --apache). إنه يجلب ويثبّت شهادة مجانية ويُعدّ التجديد التلقائي.
• أي شيء آخر: اتصل بدعم مزوّد استضافتك واطلب منهم “تفعيل شهادة SSL مجانية لنطاقي.” يقدّم جميعهم تقريباً هذا دون تكلفة.

2. أجبِر كل زائر على HTTPS (إعادة التوجيه).

• Cloudflare: SSL/TLS ← Edge Certificates ← فعّل “Always Use HTTPS.” تلك هي المهمة كلها.
• منشئو المواقع (Squarespace، Wix، Shopify، إلخ): ابحث عن مفتاح “Force HTTPS” أو “Secure (HTTPS)” في إعدادات موقعك وفعّله.
• Nginx: أضِف كتلة خادم على المنفذ 80 تعيد إعادة توجيه دائمة — return 301 https://$host$request_uri;.
• Apache (.htaccess): فعّل إعادة الكتابة وأعِد توجيه أي طلب غير HTTPS — RewriteEngine On، RewriteCond %{HTTPS} off، RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301].
• IIS (استضافة Windows): ثبّت وحدة URL Rewrite وأضِف قاعدة إعادة توجيه “HTTP to HTTPS”.

بعد تفعيل كليهما، اختبره: اكتب عنوانك مع http:// العادي في البداية وتأكد من أن المتصفح يقفز إلى نسخة https:// ذات القفل تلقائياً، وأن القفل يظهر على صفحاتك الرئيسية.

الأخطاء الشائعة

• شهادة مثبّتة، لكن دون إعادة توجيه. أكثر الثغرات شيوعاً. ترى القفل حين تزور موقعك أنت (لأن متصفحك تذكّر HTTPS)، فتفترض أنه انتهى — لكن الزوّار الجدد الذين يكتبون النطاق المجرّد لا يزالون يصلون إلى HTTP أولاً. اختبر دائماً نسخة http:// العادية صراحةً.
• المحتوى المختلط. تُحمَّل صفحتك عبر HTTPS لكنها تسحب صورة أو سكربت أو خطّاً من عنوان http:// قديم. تحجبه المتصفحات أو تخفض القفل إلى تحذير. حدّث تلك الإشارات إلى https:// (أو إلى روابط نسبية). معظم المنصات لديها تقرير “محتوى مختلط” أو “محتوى غير آمن” يعثر عليها.
• إعادة توجيه مؤقتة (302) بدلاً من دائمة (301). تعمل 302 للزوّار لكنها تُخبر محرّكات البحث بأن النقل مؤقت، فلا تنتقل قيمة الترتيب بنظافة إلى عنوانك الآمن. استخدم 301 دائمة.
• إعادة توجيه النطاق المجرّد فقط، لا “www” (أو العكس). تأكد من أن كلاً من yourdomain.com وwww.yourdomain.com ينتهي على HTTPS، وإلا فأحد المسارين لا يزال معرّضاً.
• ترك شهادة تنتهي. الشهادة المنقضية تُلقي خطأ متصفح بملء الشاشة يوقف الزوّار تماماً. شهادات Let’s Encrypt المجانية تجدّد نفسها تلقائياً؛ وإذا اشتريت واحدة يدوياً، فاضبط تذكيراً في التقويم قبل انتهائها بمدة كافية.

الأسئلة الشائعة

راجِع الأسئلة أعلاه — فهي تغطّي السؤال غير التقني “هل يمكنني فعل هذا بنفسي”، والفرق بين وجود قفل وفرض إعادة التوجيه، وتكلفة الشهادة وتجديدها، وما إذا كانت المواقع التعريفية تحتاجه، وكيف يرتبط هذا بـ HSTS.

الأسئلة الشائعة