ما مدى حماية أشهر المواقع في بولندا؟ قياس 1000 نطاق .pl (سبتمبر 2026)

أخذتُ أول 1000 نطاق .pl في تصنيف Tranco، وهو تصنيف أُعدّ للأبحاث، وفحصتُها من الخارج صباح 24 سبتمبر 2026 كما يراها أي زائر أو خادم بريد. اقتصر القياس على ما هو متاح للجميع: استعلامات DNS، وزيارة واحدة لكل صفحة رئيسية، وبضعة اتصالات TLS لكل نطاق، دون فحص للثغرات ودون أي محاولة لتسجيل الدخول. وحُسبت النتائج بالفحوص نفسها التي تعمل في أدوات ShieldWave المجانية. ولا أذكر اسم أي نطاق منها.

أهم الأرقام

• في 24 سبتمبر 2026 كانت لدى 460 من أصل 997 نطاقًا من الأكثر شعبية في بولندا (46.1%) سياسة DMARC تطلب من خوادم البريد المستقبِلة رفض الرسائل التي تنتحل النطاق أو عزلها. وبين النطاقات التي تستقبل البريد (التي لها سجلات MX) كانت 445 من أصل 927 (48.0%).
• وفي قياس 24 سبتمبر 2026 أرسلت 406 من أصل 882 صفحة رئيسية بولندية شائعة تعمل عبر HTTPS (46.0%) ترويسة HSTS، وفرضت 217 من أصل 887 (24.5%) سياسة Content-Security-Policy.
• وفي سبتمبر 2026 كانت 230 من أصل 952 نطاقًا بولنديًا شائعًا (24.2%) لا تزال تقبل اتصالات TLS 1.0. ومن هذه الـ230 يعمل 149 عبر Cloudflare، الذي يقبل TLS 1.0 ما لم يرفع صاحب النطاق الحد الأدنى للإصدار.
• ولا يوجد أي سجل DMARC في 274 من أصل 997 نطاقًا (27.5%)، وفي 248 نطاقًا آخر (24.9%) سجل مضبوط على p=none لا يحجب شيئًا.
• وفي فحص ترويسات الأمان نالت 20 من أصل 887 صفحة رئيسية (2.3%) أعلى درجة، A، ونالت 290 (32.7%) أدنى درجة، F.
• وجدتُ ملف security.txt، الذي يدل الباحثين على الجهة التي يبلّغونها عن الثغرات، في 78 موقعًا على الأقل من أصل 881 (8.9%).
• ومن بين 46 موقعًا تعلن إصدار PHP في ترويسة، يعمل 26 بإصدار لم يعد يتلقى أي إصلاحات، منها 11 بإصدار PHP 5.

حماية البريد من الانتحال: من يستطيع الإرسال باسم نطاقك

يكفي بريد مزيف يحمل عنوان شركتك في خانة «المرسل» لإرسال فاتورة مزيفة إلى أحد عملائك. وتحمي منه ثلاثة سجلات في DNS هي SPF وDKIM وDMARC، وقد شرحتُها في مقال SPF وDKIM وDMARC: شرح مبسط (بالإنجليزية). والقرار في النهاية بيد DMARC، فهو الذي يحدد لخادم المستلم ما يفعله برسالة تدّعي أنها منك ولم تجتز الفحص.

وسجل SPF منتشر في كل مكان تقريبًا: يوجد لدى 915 من أصل 999 نطاقًا (91.6%). لكن SPF وحده لا يفحص العنوان الذي يراه المستلم في خانة «المرسل». وهذا ما يفعله DMARC وحده، والأرقام هنا أقل.

• لا يوجد سجل DMARC27.5%274 من 997
• p=none: مراقبة فقط دون حجب24.9%248 من 997
• quarantine أو reject لجزء من البريد فقط (pct أقل من 100)1.5%15 من 997
• quarantine أو reject لكل البريد46.1%460 من 997

النطاقات التي أعطى DNS بشأنها إجابة قاطعة. لا يُحسب إلا السجل الخاص بالنطاق نفسه.

إذن 460 من أصل 997 نطاقًا (46.1%) تحجب الانتحال. وبين النطاقات التي لها سجلات MX، أي التي تستقبل البريد، تبلغ 445 من أصل 927 (48.0%). أما البقية فليس لديها DMARC أو لديها سجل يراقب فقط. وعندئذٍ يبقى وصول الرسالة المزيفة إلى صندوق الوارد رهنًا بفلاتر الجهة المستقبِلة وحدها.

والإعداد p=none ليس خطأ، بل هو الخطوة الأولى الموصى بها: يجمع النطاق التقارير، فيرى صاحبه من يرسل البريد باسمه. ومن أصل 723 سجلًا من سجلات DMARC، يتضمن 622 سجلًا (86.0%) عنوانًا لاستقبال التقارير المجمّعة (rua). لكن الحماية لا تبدأ إلا مع quarantine أو reject. وبين النطاقات التي لديها DMARC، الإعدادات الثلاثة شائعة بنسب متقاربة: p=none في 248 من أصل 723 (34.3%)، وquarantine في 263 (36.4%)، وreject في 212 (29.3%).

ومن أخطاء SPF الأصغر: 12 من أصل 915 سجلًا (1.3%) تحتاج إلى أكثر من 10 استعلامات DNS، وهو الحد الذي يسمح به المعيار، ونطاقان ينشران سجلَّي SPF بدل سجل واحد، ونطاق واحد ينهي سجله بـ+all، أي يسمح لأي خادم بإرسال البريد باسمه.

ولا أعرض نتائج DKIM، لأن أسماء المحددات (selectors) التي تُنشر تحتها مفاتيح DKIM لا يمكن سردها عبر DNS، فعبارة «غير موجود» لن تعني إلا «غير موجود تحت الأسماء الشائعة».

التشفير: HTTPS وHSTS وTLS

أصبح HTTPS نفسه هو القاعدة. والفروق تظهر فيما يكمّله: ترويسة HSTS، وإصدارات TLS القديمة، وسجل CAA.

تختلف المقامات لأن كل صف لا يحسب إلا النطاقات التي حصل فيها الفحص المعني على إجابة. والتفاصيل في قسم المنهجية.

HSTS ترويسة تطلب من المتصفح ألا يتصل بالنطاق إلا عبر HTTPS لمدة محددة. ومن دونها تبدأ كل زيارة لعنوان كُتب دون https:// باتصال غير مشفّر قبل أن يعيد الخادم توجيهها، ويمكن اعتراض هذا الاتصال في شبكة Wi-Fi لا تعرفها. ترسل HSTS 406 من أصل 882 صفحة رئيسية تعمل عبر HTTPS (46.0%)، وترسلها بالمدة الموصى بها، أي سنة على الأقل، 268 صفحة (30.4%).

TLS 1.0 و1.1 إصداران قديمان من بروتوكول التشفير. أوقفت المتصفحات دعمهما في 2020، وأعلنت هيئة IETF رسميًا التخلي عنهما في 2021 (RFC 8996). ولا تزال اتصالات TLS 1.0 مقبولة في 230 من أصل 952 نطاقًا (24.2%). والزائر الذي يستخدم متصفحًا حديثًا سيتصل عبر TLS 1.2 أو 1.3 على أي حال، فهذه ليست طريقًا للسيطرة على الموقع. لكنها تعني أن الخادم يقبل تشفيرًا متقادمًا إن طُلب منه ذلك، والمدققون واستبيانات الأمان التي تُرسل إلى الموردين يطلبون تعطيل الإصدارات القديمة.

ومن هذه النطاقات الـ230 يعمل 149 (64.8%) عبر Cloudflare، الذي يقبل TLS 1.0 افتراضيًا ولا يتوقف عن ذلك إلا حين يرفع صاحب النطاق الحد الأدنى للإصدار في لوحة التحكم. أما الـ81 الباقية فتقبل TLS 1.0 على خوادمها الخاصة أو لدى مزودين آخرين.

وCAA سجل في DNS يحدد جهات إصدار الشهادات المسموح لها بإصدار شهادة للنطاق، وعلى غيرها أن ترفض. وقد وجدتُه لدى 192 من أصل 999 نطاقًا (19.2%).

ترويسات الأمان

ترويسات الأمان سطور قليلة من التعليمات يرسلها الخادم إلى المتصفح مع الصفحة. وقد وصفتُها في مقال ترويسات أمان الموقع: ما هي وماذا تطلب من مطوّرك. وهذا مدى انتشارها في الصفحات الرئيسية (ترويسة HSTS في قسم التشفير أعلاه):

وفي 26 صفحة رئيسية أخرى (2.9%) توجد CSP في وضع Report-Only فقط، وفيه لا يحجب المتصفح شيئًا.

وتمنح أداة فحص ترويسات الأمان المجانية (بالإنجليزية) درجة من A إلى F: تأخذ كل ترويسة حرفًا، وتُحسب HSTS وCSP مرتين والبقية مرة واحدة، ويعطي المتوسط الدرجة النهائية. وقد استخدمتُ السلّم نفسه في هذا القياس.

• A2.3%20 من 887
• B21.8%193 من 887
• C21.1%187 من 887
• D22.2%197 من 887
• F32.7%290 من 887

سلّم أداة فحص الترويسات المجانية من ShieldWave. تُحسب HSTS وCSP مرتين، والترويسات الأخرى مرة واحدة.

الدرجة F لا تعني أن في الموقع ثغرة، والدرجة A لا تضمن خلوه منها. فالترويسات خط دفاع ثانٍ يحد من الضرر حين يخفق شيء آخر. وغيابها يعني عادة أن الخادم يعمل بإعداداته الافتراضية التي لا تضيفها، وكثيرًا ما تضيفها لاحقًا شبكة CDN أو إضافة.

وفي اليوم نفسه وبالطريقة نفسها قستُ أشهر 500 نطاق .ae وأشهر 500 نطاق .sa (الإمارات والسعودية). صفحاتها الرئيسية فيها CSP (280 من 656، أي 42.7%) وHSTS (408 من 652، أي 62.6%) أكثر مما في الصفحات البولندية. والمقارنة تقريبية: فقائمتا الإمارات والسعودية تمتدان أعمق في التصنيف، ولم يكن تحليل 344 صفحة من أصل 1000 فيهما ممكنًا من بولندا. والتفاصيل في عرض ذلك القياس.

المنصات والبرمجيات القديمة

تعرّفتُ على المنصة في صفحة رئيسية واحدة من كل أربع. ففي 663 من أصل 884 صفحة رئيسية (75.0%) لم أجد أثرًا لأي منصة معروفة: إما مواقع مبنية خصيصًا، وإما مواقع لا تكشف ما تعمل عليه. لذا فالنسب التالية حدود دنيا.

يعمل WordPress في 101 من أصل 884 صفحة رئيسية (11.4%). ويليه Drupal (25)، وMagento (21)، وTYPO3 (13). أما منصات المتاجر البولندية (IdoSell وShoper وAtomStore وRedCart) فتعمل 12 صفحة بينها جميعًا.

وإصدار WordPress ظاهر في 54 من الـ101. وهي أعداد صغيرة، لذا أذكرها دون نسب:

• 28 من الـ54 لا تعمل بأحدث إصدار، وهو 7.1.2،
• 22 تعمل بفرع أقدم من 7.1،
• 18 ليست على آخر إصدار من فرعها نفسه، أي تنقصها تحديثات أمنية صدرت بالفعل لذلك الفرع،
• وأقدم إصدار ظاهر هو WordPress 3.5.1، من عام 2013.

ولا تعلن عن إصدار PHP في ترويساتها إلا 46 من أصل 887 صفحة رئيسية، فهذه الأرقام تصف تلك الصفحات الـ46 وحدها لا الإنترنت كله. ومنها 26 تعمل بفروع لم تعد تتلقى أي إصلاحات (8.1 وما قبله)، و11 منها بإصدار PHP 5 الذي انتهى دعم آخر فروعه في نهاية 2018. و12 أخرى تتلقى تحديثات أمنية فقط (8.2 و8.3)، و8 مدعومة بالكامل (8.4 و8.5).

ويظهر اسم الخادم مع رقم إصداره، مثل Apache/2.4.41، في ترويسات 74 من أصل 887 صفحة رئيسية (8.3%). والكشف عن الإصدار ليس ثغرة في حد ذاته، لكنه يضيّق دائرة الثغرات المعروفة التي تنطبق على الخادم.

ولم أفحص الإضافات في هذا القياس. وإن كان موقعك يعمل على WordPress، فابدأ بمقال إضافات WordPress القديمة: ماذا تحدّث أولًا وماذا تحذف.

ملف security.txt: أين يُبلَّغ عن الثغرات

يحدد ملف /.well-known/security.txt (المعيار RFC 9116) العنوان الذي يستطيع الباحث الأمني أن يبلّغ عبره عن ثغرة وجدها. ومن دونه يذهب البلاغ إلى عنوان تواصل عام، أو لا يصل إلى أحد.

وجدتُ الملف مع حقل Contact: في 78 موقعًا من أصل 881 (8.9%). وهذا حد أدنى، فهناك 41 موقعًا أخرى أجابت بإعادة توجيه إلى ملف security.txt في عنوان آخر، ولم أتتبع عمليات إعادة التوجيه. ولو قادت كلها إلى ملف صالح لبلغ العدد 119 من أصل 881 (13.5%). ومن بين الملفات الـ78 يتضمن 55 ملفًا حقل Expires الذي يشترطه المعيار.

أدوات التتبع ومنصات الموافقة

هذا الجزء وصفي. لم أشغّل JavaScript، فلا أرى إلا الأدوات المذكورة في كود HTML للصفحة الرئيسية. ولا أستطيع أن أعرف هل تعمل ومتى: فقد ينتظر السكربت موافقة الزائر، وقد يحمّل Google Tag Manager أدوات لا تظهر في كود الصفحة.

• Google Tag Manager45.6%403 من 884
• Google Analytics30.3%268 من 884
• Gemius12.3%109 من 884
• Meta Pixel10.2%90 من 884
• Microsoft Clarity3.4%30 من 884
• Hotjar2.5%22 من 884
• Matomo2.0%18 من 884

بأي شكل: سكربت، أو مقتطف تثبيت، أو استدعاء فقط. وجودها في الكود لا يبين هل تعمل قبل الموافقة.

ويظهر Google Analytics أو Google Tag Manager في كود 572 من أصل 884 صفحة رئيسية (64.7%). أما Gemius، نظام قياس الجمهور في بولندا، ففي 109 من أصل 884 (12.3%). ووضع الموافقة من Google (Consent Mode) مع الرفض الافتراضي، وفيه تعمل أدوات Google دون ملفات تعريف الارتباط إلى أن يوافق الزائر، يظهر في 103 من أصل 884 صفحة رئيسية (11.7%).

وظهرت منصة معروفة لإدارة الموافقة، مثل Cookiebot وOneTrust وDidomi أو منصة تستخدم إطار IAB TCF، في 293 من أصل 884 صفحة رئيسية (33.1%). ولا يعني ذلك أن بقية المواقع تخلو من نافذة الموافقة: فالنوافذ المبنية خصيصًا، أو المدمجة في منصات المتاجر، والأدوات المحمّلة عبر Google Tag Manager، لا تراها هذه الطريقة. لذلك لا أستخلص من هذه الأرقام أي حكم على الامتثال للأنظمة.

ماذا يعني هذا لشركتك

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

1. البريد. افحص نطاقك بأداة اختبار SPF وDKIM وDMARC (بالإنجليزية). وإن لم يكن لديك DMARC، أو كان مضبوطًا على p=none، فانتقل إلى quarantine خطوة بخطوة كما في مقال SPF وDKIM وDMARC: شرح مبسط (بالإنجليزية). فهذا ما يحميك من فواتير مزيفة تُرسل من نطاقك.
2. التشفير. تُظهر أداة فحص شهادة SSL (بالإنجليزية) الشهادة، وإعادة التوجيه إلى HTTPS، وإصدارات TLS. وإن كان موقعك خلف Cloudflare، فغيّر الحد الأدنى من لوحة التحكم: SSL/TLS، ثم Edge Certificates، ثم Minimum TLS Version. واختر TLS 1.2.
3. الترويسات. تُظهر أداة فحص ترويسات الأمان (بالإنجليزية) ما ينقص موقعك. وفي مقال ترويسات أمان الموقع نص جاهز لمطوّرك: ابدأ بترويسة HSTS بمدة max-age قصيرة، وبسياسة CSP في وضع Report-Only.
4. ملف security.txt. انشر الملف /.well-known/security.txt وفيه حقلا Contact وExpires. إنه بضعة أسطر من النص.
5. البرمجيات. حدّث نظام إدارة المحتوى والإضافات، واحذف أرقام الإصدارات من ترويسات الخادم. وفي WordPress راجع مقال إضافات WordPress القديمة.
6. التتبع والموافقة. تُظهر أداة ملفات تعريف الارتباط قبل الموافقة (بالإنجليزية) هل تضع صفحتك الرئيسية ملفات تتبع، أو تحمّل أدوات التحليلات والإعلانات، قبل أن يوافق الزائر. وإن كنت مسؤول حماية بيانات (DPO) فراجع أيضًا مقال ما يستطيع مسؤول حماية البيانات فحصه في موقع العميل دون خبرة تقنية.

وإن كان عملاؤك يخضعون لتوجيه NIS2، فإن استبيانات الموردين لديهم تسأل عن الإعدادات نفسها. ويشرح مقال NIS2 وموقعك كيف تستعد.

المنهجية

النطاقات. قائمة Tranco رقم L5PV4، التي أُنشئت في 23 سبتمبر 2026 الساعة 22:00 بتوقيت UTC من بيانات 30 يومًا (من 25 أغسطس إلى 23 سبتمبر 2026) لخمسة مزودين: Chrome UX Report وFarsight وMajestic وCloudflare Radar وCisco Umbrella. وTranco تصنيف أُعدّ للأبحاث ويقاوم التلاعب. اخترتُ أول 1000 نطاق ينتهي بـ.pl بترتيب التصنيف، بما فيها النطاقات من المستوى الثاني مثل com.pl وgov.pl وedu.pl. وفي المليون الأول من Tranco يوجد 9,214 نطاقًا .pl، وتقع مراتب الـ1000 المختارة منها بين 667 و136,495. وTranco يرتب النطاقات لا المواقع، لذا تضم القائمة أيضًا نطاقات تقنية (شبكات CDN وخوادم الإعلانات والقياس) ليست لها صفحة رئيسية.

الزمان والمكان. 24 سبتمبر 2026، من 07:39 إلى 07:43 بتوقيت UTC (من 09:39 إلى 09:43 بتوقيت بولندا)، من اتصال شبكة واحد في بولندا. وذهبت استعلامات DNS إلى الخوادم العامة 1.1.1.1 و8.8.8.8. وقدّم كل طلب HTTP نفسه باسم ShieldWaveResearch/1.0 مع رابط shieldwave.io، ولم يتظاهر بأنه متصفح.

ما الذي أُرسل. لكل نطاق، فقط:

1. استعلامات DNS: العناوين، وMX، وTXT (لسجلي SPF وDMARC)، وCAA،
2. زيارة واحدة للصفحة الرئيسية (https://، أو http:// إن لم يُجب HTTPS، بحد أقصى 5 عمليات إعادة توجيه)،
3. طلب http:// واحد عادي لمعرفة هل يعيد التوجيه إلى HTTPS،
4. اتصالات TLS على المنفذ 443: مصافحة كاملة واحدة وأربع محاولات للإصدارات (1.0 و1.1 و1.2 و1.3)،
5. طلب واحد للملف /.well-known/security.txt.

ولا شيء غير ذلك: لا بحث عن ملفات أو لوحات تحكم أو نسخ احتياطية، ولا نماذج، ولا تسجيل دخول، ولا حمولات اختبار.

الفحوص نفسها التي في الأدوات المجانية. حُسبت النتائج بالكود نفسه الذي تعمل به أدوات ShieldWave المجانية (الشهادة، والبريد، والترويسات، وملفات تعريف الارتباط)، في الإصدار 8db196d. فيستطيع أي أحد أن يفحص نطاقه بالمقياس نفسه.

المقامات والاستبعادات. لكل رقم مقامه الخاص، لأن كل فحص لا يحصل على إجابة من كل نطاق. ومن بين 1000 نطاق أمكن تحليل 887 صفحة رئيسية. ومن البقية لم يُجب 38 نطاقًا بأي استجابة HTTP (13 منها ليس لها عنوان في DNS أصلًا)، وأجاب 52 بفحص للروبوتات أو بحجب مثل الرمز 403، وأعاد 23 خطأً آخر. هذه الـ113 مستبعدة من أرقام الصفحات (الترويسات وHTML وsecurity.txt وإعادة التوجيه)، لكنها تبقى في أرقام DNS والبريد وTLS التي لا تعتمد على الصفحة. وأرقام DNS لا تحسب إلا الإجابات القاطعة (في DMARC: 997 من أصل 1000).

التعريفات. سياسة DMARC التي تحجب الانتحال هي سجل النطاق الخاص الذي فيه p=quarantine أو p=reject مع pct=100 أو دون pct. ولا يُحسب السجل الموروث من نطاق أعلى. ولا تُحسب HSTS إلا في الصفحات التي تنتهي بعنوان HTTPS، ولا CSP إلا حين تكون مفعّلة. ويُحسب security.txt حين تكون الإجابة بالرمز 200 وفيها حقل Contact:، ولا تُحسب صفحة HTML أبدًا.

حدود القياس.

• الصفحة الرئيسية فقط، وزيارة واحدة، في يوم واحد. وقد ترسل الصفحات الأخرى ترويسات مختلفة.
• دون JavaScript: أدوات التتبع ومنصات الموافقة مقروءة من كود HTML، ولا أرى ما يحمّله Google Tag Manager ولا ما تخزّنه السكربتات لاحقًا.
• كثير من النتائج يعكس الإعدادات الافتراضية لشبكات CDN والاستضافة (TLS 1.0 على Cloudflare، وترويسات تضاف أو لا تضاف على حافة الشبكة).
• المواقع التي حجبت الزيارة الآلية غائبة عن أرقام الصفحات، وقد تختلف عن المواقع الباقية.
• ملف security.txt حد أدنى، لأنني لم أتتبع إعادة التوجيه.
• التعرف على المنصات حد أدنى (75.0% من الصفحات دون منصة معروفة).
• لا أعرض نتائج DKIM.
• القياس من بولندا: المواقع التي تغيّر ما تعرضه بحسب موقع الزائر قد تبدو مختلفة من مكان آخر.

التكرار والتحقق. قبل نحو ربع ساعة أجريتُ تشغيلًا كاملًا أول على القائمة نفسها. ولا أنشره لأنني صحّحتُ كشف Gemius بعده. وباستثناء أرقام Gemius، لم يختلف أي مؤشر من المؤشرات الـ250 بين التشغيلين بأكثر من 0.9 نقطة مئوية، وكان الفرق الوسيط 0.0. وفي تحقق مستقل أعدتُ قياس 36 نطاقًا مختارًا عشوائيًا، منها 20 من القائمة البولندية، بأدوات أخرى: DMARC وSPF عبر خادم DNS مختلف (9.9.9.9)، وHSTS وترويسة Server عبر curl، وTLS 1.0 عبر openssl، وsecurity.txt عبر curl. وتطابقت النتائج في جميع المقارنات، وعددها 216.

البيانات. لا أنشر البيانات الخام لأنها تسمي مواقع بعينها. أما البيانات المجمّعة فمتاحة للتنزيل مجانًا بترخيص CC BY 4.0، ولكل رقم فيها البسط والمقام والنسبة والفئة التي حُسب منها: pl-2026-09.csv وpl-2026-09.json. ويمكن تكرار القياس: قائمة Tranco منشورة، وكل فحص يعمل في أدوات ShieldWave المجانية.

كيف تقتبس هذه الأرقام

باختصار: المصدر: ShieldWave، قياس أشهر 1000 نطاق .pl في 24 سبتمبر 2026، https://shieldwave.io/blog/polish-websites-security-2026/

بالتفصيل: رادوسواف فيدورتشوك (ShieldWave، ENSOMEDIA)، «ما مدى حماية أشهر المواقع في بولندا؟ قياس 1000 نطاق .pl (سبتمبر 2026)»، 24 سبتمبر 2026، https://shieldwave.io/blog/polish-websites-security-2026/. البيانات المجمّعة بترخيص CC BY 4.0.

وللأسئلة عن المنهجية أو البيانات: support@shieldwave.io