عبدالله عبدالرحيم بن سنكر: خرافات التحقق من المدخلات في الواجهة والخادم
عبدالله عبدالرحيم بن سنكر يصحح أشهر الخرافات عن التحقق من المدخلات: ليش الواجهة ما تكفي، وليش الخادم لحاله ما يكفي، وكيف تتعامل مع الأرقام العربية وأرقام الجوال.

التحقق من المدخلات
عبدالله عبدالرحيم بن سنكر
نموذج تسجيل فيه خمس خانات، ما أحد يعطيه وقتاً في تقدير المشروع. لكن من هذي الخانات يدخل أغلب البلاء: بيانات مخربطة تخرّب التقارير، وأرقام جوال ما توصلها رسائل، وطلبات معدّلة تشتري منتجاً بسعر غير سعره. عبدالله عبدالرحيم بن سنكر يبني واجهات بـ Flutter و Next.js وأنظمة خلفها، ويسمع نفس القناعات الغلط عن التحقق من المدخلات في كل مشروع تقريباً. هذي أشهرها، وكل خرافة جنبها الحقيقة اللي تصححها.
الخرافة: «حطينا تحقق في الواجهة، خلاص»
الحقيقة: الواجهة ملك المستخدم، مو ملكك. أي شخص يقدر يفتح أدوات المطوّر في المتصفح ويشيل شرط الحقل، أو يتجاهل التطبيق كله ويرسل الطلب مباشرة للخادم بأداة مثل curl. لو كان سعر المنتج أو نسبة الخصم أو معرّف المستخدم يجي من الطلب والخادم يصدقه، فأي أحد يقدر يغيّره. تحقق الواجهة يحمي المستخدم الصادق من الأخطاء، والخادم وحده هو اللي يحميك من غير الصادق. والقاعدة اللي تختصر الموضوع: أي قيمة تجي من خارج خادمك مشكوك فيها لين تثبت العكس، حتى لو جت من تطبيقك أنت.
الخرافة: «دام الخادم يتحقق، الواجهة ما تحتاج»
الحقيقة: هذا آمن بس متعب. المستخدم يعبّي عشر خانات، يضغط إرسال، ينتظر، ثم يرجع له خطأ عام فوق النموذج. يصلح ويرسل، فيطلع خطأ ثاني. التحقق في الواجهة وظيفته التجربة: رسالة واضحة تحت الخانة نفسها، وقت ما يخلص المستخدم من الكتابة، مو بعد ما يضغط إرسال. والنتيجة نماذج تكتمل أكثر وطلبات أقل للخادم. الاثنين مطلوبين، لكن كل واحد لسبب مختلف.
الخرافة: «التحقق يعني نتأكد إن الصيغة صحيحة»
الحقيقة: الصيغة أول طبقة من أربع. بريد إلكتروني بصيغة سليمة ممكن يكون بريد شخص ثاني، وتاريخ صحيح ممكن يكون في الماضي وهو موعد حجز. الطبقات كاملة:
- الشكل والنوع: هل الحقل موجود، وهل هو رقم فعلاً، وهل طوله في الحدود؟ وحد الطول مهم حتى للحقول اللي تبان غير مهمة، لأن نصاً من مليون حرف في خانة الاسم ممكن يثقّل الخادم والقاعدة.
- الصيغة: البريد بشكل بريد، والجوال بشكل جوال، والرمز البريدي بعدد أرقامه.
- قواعد العمل: الكمية ما تتجاوز المخزون، وتاريخ الحجز في المستقبل، وكود الخصم ساري وما استُخدم أكثر من المسموح.
- الصلاحية: هل هذا المعرّف يخص هذا المستخدم؟ طلب «احذف الطلب رقم ١٠٢٥» صيغته سليمة، لكن لو الطلب يخص عميلاً ثانياً فهو ثغرة مشهورة اسمها IDOR.
وفيه طبقة خامسة ينساها كثير: الحقول اللي ما طلبتها. لو النموذج يرسل الاسم والبريد، والخادم يحفظ كل اللي يجيه في الطلب كما هو، فشخص يضيف حقل role بقيمة admin ممكن يرقّي نفسه. اقبل الحقول المعروفة بالاسم، وتجاهل أو ارفض أي شي ثاني.
الخرافة: «نظّف المدخلات من الرموز الخطيرة وانتهينا من الحقن»
الحقيقة: محاولة حذف «الرموز الخطيرة» لعبة خاسرة، لأنك تحتاج تعرف كل طريقة ممكنة للهجوم، والمهاجم يحتاج طريقة وحدة نسيتها. وفي نفس الوقت تخرّب بيانات سليمة: اسم فيه فاصلة عليا، أو عنوان فيه شرطة. الحماية الصحيحة تكون في المكان اللي تُستخدم فيه البيانات. في قاعدة البيانات: استعلامات بمعاملات Parameterized، ما تلصق فيها نص المستخدم داخل جملة SQL أبداً. وفي الصفحة: ترميز المخرجات حسب السياق، والأطر الحديثة مثل React تسويه افتراضياً للنص، إلا لو تجاوزته بنفسك بإدخال HTML خام. وفي التحقق نفسه: قائمة سماح تحدد المقبول، مثل «أرقام فقط وطولها كذا»، أقوى من قائمة منع تحاول تحصر الممنوع.
الخرافة: «المدخلات العربية مثل الإنجليزية»
الحقيقة: المستخدم العربي يكتب بطرق ما يتوقعها النموذج المصمم بعقلية إنجليزية، والتحقق الصارم بدون تطبيع يرفض بيانات صحيحة:
- الأرقام: كثير من المستخدمين يكتبون ٠٥٥ بالأرقام العربية. حوّلها للأرقام اللاتينية قبل التحقق، بدل ما ترفض رقم جوال سليم.
- رقم الجوال السعودي: يجي بصيغ مختلفة، مثل ٠٥ في أوله، أو 9665 بعد علامة الزائد، أو 009665. اقبل كلها، ثم خزّنه بصيغة دولية موحّدة.
- المسافات: مسافة زائدة في آخر البريد أو مسافات بين أرقام الجوال تنشال قبل التحقق، مو تطلع خطأ للمستخدم.
- الأسماء: لا ترفض الاسم لأن فيه مسافات أو «بن» أو «آل»، ولا تفرض حداً أدنى غريباً لطول الاسم.
- البحث مو تحقق: الهمزات والتاء المربوطة تُوحّد وقت البحث عشان «احمد» يلقى «أحمد»، لكن الاسم يُحفظ كما كتبه صاحبه.
الحقيقة اللي تجمع الكل: قواعد وحدة، ومكانين للتنفيذ
أسهل طريقة تخلي الواجهة والخادم متفقين إنك تكتب قواعد التحقق مرة وحدة. في مشاريع TypeScript و Next.js، مكتبة مثل Zod تخليك تعرّف مخطط النموذج مرة، وتستخدمه في المتصفح لعرض الأخطاء، وفي الخادم أو Server Action لرفض الطلب، فما يصير الحقل إجبارياً في مكان واختيارياً في الثاني. وفي Flutter، دوال التحقق في حقول النموذج تخدم التجربة، والخادم يطبق نفس القواعد من جهته. ورسائل الخطأ جزء من التحقق: «رقم الجوال لازم يبدأ بـ ٠٥ ويتكون من عشرة أرقام» أفضل بكثير من «مدخل غير صالح». مع استثناء واحد مقصود: في تسجيل الدخول واستعادة كلمة المرور، لا تقول «هذا البريد غير مسجّل»، لأنك بهذا تعطي أي أحد أداة يكتشف فيها مين عنده حساب عندك.
في منصة أزهل الرقمية، عبدالله عبدالرحيم بن سنكر الكندي يتعامل مع كل نموذج كباب للنظام: الواجهة ترحّب وتساعد، والخادم يفتّش ويقرر. وإذا كان لازم تختار واحد بس بسبب الوقت، فاختر الخادم دائماً، لأن التجربة السيئة تخسرك مستخدماً، أما الخادم المفتوح فيخسرك النظام كله.
عندك فكرة؟ الاستشارة الأولى علينا
كلّم عبدالله مباشرة على واتساب — رسالتك توصل له هو، مو لرد آلي. نسمع فكرتك ونقول لك وش تحتاج وكم تكلّف، ببلاش.
مقالات ذات صلة
كل المقالات
أمان خوادم MCP
عبدالله عبدالرحيم بن سنكر
ربط Claude بأدواتك الداخلية عبر MCP بأمان مع عبدالله عبدالرحيم بن سنكر
عبدالله عبدالرحيم بن سنكر يراجع ربط Claude بأنظمة الشركة عبر خوادم MCP طبقة طبقة: مكان التشغيل، والهوية والتوكنات، وحدود الأدوات، والمحتوى المسموم، والتدقيق.
اقرأ المقال
عرض فكرة مشروع
عبدالله بن سنكر
عبدالله بن سنكر: اعرض فكرة مشروعك الرقمي في صفحة وحدة
قالب صفحة وحدة يشرحه عبدالله بن سنكر لعرض فكرة مشروعك الرقمي على منفّذ أو شريك أو ممول: تسعة أقسام بالترتيب، ومثال افتراضي لكل قسم، وأخطاء تخلي القارئ يقفل الصفحة.
اقرأ المقال
تسويق B2B
عبدالله بن سنكر
عبدالله بن سنكر: أخطاء تسويق الخدمات التقنية للشركات B2B
بيع خدمة تقنية لشركة مو مثل البيع لفرد. عبدالله بن سنكر يعدد أخطاء تتكرر في تسويق B2B: تجاهل صاحب القرار الحقيقي، والعرض الفني المبهم، وإهمال أسئلة الأمان والعقود.
اقرأ المقال