لماذا تسرّب عناوين URL معلومات حساسة وكيف تمنع ذلك

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

أين يتسرب عنوان URL

• سجل المتصفح. يُخزَّن كل عنوان يزوره المستخدم على جهازه، وقد يُزامَن مع أجهزته الأخرى ومع خدمة المزامنة لدى الشركة المطورة للمتصفح.
• سجلات الوصول في خادم HTTP. تسجل معظم الخوادم مسار الطلب وسلسلة الاستعلام كاملين افتراضيًا، فكل من يصل إلى السجلات يملك العنوان.
• الوكلاء العكسيون وشبكات CDN. Cloudflare و Fastly وموازن الأحمال لديك: كلها تسجل العنوان، ولكل منها سياسة احتفاظ خاصة بها.
• أنظمة تجميع السجلات. نادرًا ما تبقى سجلات الوصول على جهاز واحد، إذ تُرسل إلى خدمات مركزية للتسجيل والمراقبة، فيتضاعف عدد الأنظمة التي تحتفظ بالعنوان.
• ترويسات Referer. حين ترتبط الصفحة بمورد من طرف ثالث، قد يرسل المتصفح عنوان الصفحة المصدر في الترويسة Referer. وتتلقاه سكربتات الإحصاءات ومقاطع الفيديو المضمّنة وبكسلات الإعلانات جميعها.
• إضافات المتصفح. الإضافات التي تملك صلاحية «قراءة سجل التصفح» ترى كل عنوان، بما في ذلك الجزء الذي يلي علامة #.
• مزامنة الإشارات المرجعية. تُزامَن العناوين المحفوظة في الإشارات المرجعية بين أجهزة المستخدم ومع خوادم الشركة المطورة للمتصفح.
• أدوات معاينة الروابط. تجلب Slack و Teams و iMessage و LinkedIn وبرامج البريد الإلكتروني العناوين لعرض معاينات لها، بصمت، في لحظة إرسال الرسالة.
• وكلاء الشركات وبوابات البريد الإلكتروني. تفحص مؤسسات كثيرة كل عنوان يعبر حدودها وتعيد كتابته وتسجله.

هل يحافظ HTTPS على خصوصية عنوان URL؟

لا. يشفّر HTTPS العنوان أثناء نقله ولا شيء غير ذلك، ويظل كل من الطرفين يخزنه. والدقة هنا مهمة، لأن عبارة «الاتصال مشفر» تُفهم خطأً على أنها «العنوان خاص».

يشفّر TLS المسار وسلسلة الاستعلام أثناء النقل: فمن يراقب الشبكة بين المتصفح والخادم لا يستطيع قراءة /reset?token=.... أما ما لا يخفيه TLS فهو اسم المضيف الذي يقصده الطلب (وهو ظاهر عبر استعلام DNS وعبر حقل SNI في TLS في معظم الاتصالات اليوم)، وكل ما يحدث عند الطرفين: فالمتصفح يظل يسجل العنوان كاملًا في السجل، والخادم يظل يكتبه في سجل الوصول. التشفير أثناء النقل يحمي الطريق لا الطرفين، والطرفان هما حيث تتسرب العناوين.

مثال عملي: رحلة عنوان واحد

تتبّع عنوانًا حساسًا واحدًا، وليكن رابط إعادة تعيين كلمة المرور https://example.com/reset?token=8f3a91...، من لحظة إرساله إلى لحظة النقر عليه:

1. مزود البريد يخزن الرسالة (والعنوان معها) إلى أجل غير محدد، وقد يجلب ماسحه الأمني العنوان عند التسليم.
2. بوابة البريد لدى المستلم تعيد كتابة العنوان وتسجله، ثم تجلبه مرة أخرى عند النقر.
3. نظام DNS يحلّ example.com، فيصبح اسم المضيف (لا المسار) في سجلات محلّل DNS.
4. خادم الويب يكتب سطر الطلب كاملًا في سجل الوصول. وهكذا يبدو سطر بالصيغة الافتراضية «combined» في nginx أو Apache:

203.0.113.7 - - [14/Jul/2026:09:12:45 +0000]
  "GET /reset?token=8f3a91... HTTP/1.1" 200 5123 "-" "Mozilla/5.0 ..."

5. شبكة CDN التي تقف أمامه تسجل العنوان نفسه بمدة احتفاظ خاصة بها.
6. سكربت الإحصاءات في الصفحة يسجل عنوان الصفحة، بسلسلة الاستعلام وكل ما فيها، في نظام لدى طرف ثالث، ما لم يُضبط صراحةً على حذفها.
7. المتصفح يخزن العنوان في السجل ويزامنه.

إرسال واحد، وسبع نسخ، تحتفظ بها خمس مؤسسات على الأقل. ولم يحتج شيء من هذا إلى مهاجم، فهذا هو الويب يعمل كما صُمم.

ترويسة Referer في الواقع العملي

إذا كانت صفحة إظهار السر لديك ترتبط بأي مورد خارجي (خط من شبكة CDN، أو سكربت إحصاءات، أو صورة مضمّنة)، فقد يرسل المتصفح عنوان الصفحة في الترويسة Referer إلى ذلك المصدر.

تعتمد المتصفحات الحديثة افتراضيًا السياسة strict-origin-when-cross-origin (MDN: Referrer-Policy)، التي تقتطع المُحيل في الطلبات بين المصادر المختلفة فتبقي المصدر وحده (https://example.com/ بدل المسار الكامل). هذا تقدم حقيقي، لكنه ليس شيئًا تعتمد عليه: فالطلبات داخل المصدر نفسه ما زالت تحمل العنوان كاملًا، والسياسة المضبوطة على مستوى الصفحة قد تخفف الإعداد الافتراضي، وبرامج العميل القديمة وواجهات العرض المضمّنة تتفاوت في سلوكها.

إجراءان عمليان للحد من ذلك:

<!-- Strip the referer for outbound requests on the page -->
<meta name="referrer" content="no-referrer" />

Referrer-Policy: no-referrer

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

هل الرمز أكثر أمانًا في المسار أم في سلسلة الاستعلام أم بعد علامة #؟

الجزء الذي يلي علامة # هو وحده الذي يبقى خارج الطلب، ولذلك فهو وحده الذي يبقى خارج سجلات الخادم، أما المسار وسلسلة الاستعلام فمتساويان. ومكان الرمز في العنوان يحدد من يراه:

الجزء الذي يلي علامة # مختلف فعلًا: فبحسب RFC 3986، القسم 3.5 يُعالَج في جهة العميل ولا يُضمَّن أبدًا في طلب HTTP، ولهذا تضع أدوات اللصق المشفرة من طرف إلى طرف مفتاح فك التشفير فيه، فهو لا يصل إلى الخادم أصلًا. لكنه ليس خفيًا تمامًا: فهو يظهر في سجل المتصفح، وتستطيع الإضافات وأي شيفرة JavaScript تعمل في الصفحة قراءته. أما الفرق بين المسار وسلسلة الاستعلام فلا أثر له على الخصوصية، لأن كليهما ينتهي في السجلات نفسها.

مشكلة رموز إعادة تعيين كلمة المرور

الرموز الحساسة في العناوين فئة ثغرات معروفة، ويصف البند CWE-598 في قائمة MITRE («Use of GET Request Method With Sensitive Query Strings») هذه الحالة بالضبط: البيانات الحساسة في سلاسل الاستعلام تنتهي في السجلات وسجلات التصفح وترويسات المُحيل مهما كان تشفير النقل. ولهذا لا تعتمد عمليات إعادة تعيين كلمة المرور المصممة جيدًا أبدًا على سرية العنوان وحدها. فهي تجعل الرمز صالحًا لاستخدام واحد وقصير العمر ومرتبطًا بإجراء لاحق (تعيين كلمة مرور جديدة)، فيصبح الرمز المستخرج من سجل بعد ثلاثة أسابيع بلا قيمة.

وهذا هو الدرس العام: لا تستطيع عادةً إبقاء العنوان خارج السجلات، لكنك تستطيع أن تجعل العنوان المسجَّل بلا قيمة حين يقرؤه أحد.

تصميم عناوين لا يضر تسربها

افترض أن كل عنوان تنشئه سيظهر يومًا ما في مكان لم تقصده، وصمّمه بحيث لا يهم ذلك:

• الاستهلاك لمرة واحدة. احذف السر نهائيًا بعد أول قراءة ناجحة، فيكون العنوان المتسرب قد انتهى حين يظهر في سجل أحدهم.
• مدة صلاحية قصيرة. قلّص الفترة التي ينفع فيها العنوان المتسرب. فالعنوان الذي عمل خمس دقائق أقل قيمة بكثير من عنوان عمل أسبوعًا.
• عبارة مرور عبر قناة أخرى. اشترط سرًا لم يكن في العنوان قط، فلا يكفي العنوان وحده، وهو الشيء الوحيد الموجود في السجلات.
• الفصل بين الجلب والإظهار. قدّم البيانات الوصفية عند طلب GET، ولا تسلّم المحتوى إلا عند طلب POST صريح، فلا تستطيع روبوتات المعاينة والماسحات استهلاك السر.
• لا موارد من أطراف ثالثة في الصفحات الحساسة، مع Referrer-Policy: no-referrer و <meta name="robots" content="noindex">.
• احجب المسارات السرية في سجلاتك أنت. في nginx، حوّل عنوان الطلب قبل تسجيله (راجع مرجع ngx_http_log_module بشأن log_format):

map $request_uri $loggable_uri {
    ~^/s/   "/s/[redacted]";
    default $request_uri;
}
log_format redacted '$remote_addr - $remote_user [$time_local] '
                    '"$request_method $loggable_uri" $status';
access_log /var/log/nginx/access.log redacted;

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

كيف يحدد هذا تصميم الروابط السرية

نموذج التهديد هذا هو سبب عمل الروابط السرية في LinkPilot على هذا النحو: نتعامل مع العنوان على أنه سيتسرب حتمًا، فلا يكفي العنوان وحده أبدًا. طلب GET لا يعيد إلا البيانات الوصفية، والمحتوى يتطلب إظهارًا صريحًا بطلب POST، ويمكن حمايته بعبارة مرور تُجزَّأ بخوارزمية SHA-256 في جهة العميل. والأسرار التي حُذفت نهائيًا أو انتهت صلاحيتها أو أُبطلت تعيد HTTP 410 بعد الكتابة فوق محتواها بلا رجعة، وتحمل ردود الإظهار Cache-Control: no-store، وتسجل أحداث العرض عنوان IP مجزّأً بملح يتغيّر يوميًا بدل العنوان الخام. وهناك حد واحد نذكره بصراحة في صفحة بنية الأمان: مفتاح فك التشفير يُنقل في الجزء الذي يلي علامة # في الرابط، فيجب التعامل مع الرابط كله على أنه السر، وهذا بالضبط هو الخطر الذي يتناوله هذا المقال. فمدة الصلاحية القصيرة والحذف بعد القراءة وعبارة المرور المرسلة عبر قناة أخرى هي ما يحد من الضرر حين يتسرب الرابط.

تحديث، 29 سبتمبر 2026: كانت هذه الفقرة تقول في الأصل إن LinkPilot لا يوفر التشفير من طرف إلى طرف. أما الآن فيشفّر المحتوى النصي في المتصفح، والمرفقات معه.

الحدود

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

قراءات ذات صلة

• كيف تعمل الروابط السرية لمرة واحدة
• أدوات فحص الروابط والأسرار لمرة واحدة
• مشاركة كلمات المرور بأمان: مقارنة بين 5 طرق

المراجع

• IETF، RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, section 3.5 Fragment.
• MDN Web Docs، Referrer-Policy header.
• nginx، Module ngx_http_log_module.