التحقق من صحة الإدخال في تطبيقات الجوال — الأساسيات وطرق الفحص والتنفيذ

ما هو التحقق من صحة الإدخال؟

التحقق من صحة الإدخال هو فحص البيانات التي تصل إلى التطبيق من مستخدم أو خدمة خارجية أو مكوّن آخر للتأكد من مطابقتها للمعايير المتوقعة. تشمل هذه المعايير نوع البيانات (سلسلة نصية، رقم، تاريخ)، والتنسيق (بريد إلكتروني، URL، هاتف)، ونطاق القيم (العمر من 18 إلى 120)، والطول (كلمة المرور من 8 إلى 128 حرفًا)، والأحرف المسموحة (الحروف اللاتينية فقط، الأرقام، الواصلة). بدون التحقق، قد يعالج التطبيق بيانات تسبب أخطاء تنفيذ أو تلف البيانات أو ثغرات أمنية.

لماذا يُعد التحقق عنصرًا أمنيًا حرجًا؟

غياب التحقق من صحة الإدخال هو السبب الجذري لثغرات مثل SQL Injection وXSS وCommand Injection وPath Traversal وBuffer Overflow. وفقًا لـ MITRE CWE (2025)، يحتل CWE-20 (Improper Input Validation) المرتبة الثانية في تصنيف أخطر أخطاء البرمجيات. التحقق هو خط الدفاع الأول في نموذج الأمان Defense in Depth: فهو يستبعد البيانات غير الصحيحة قبل وصولها إلى مكونات النظام الأخرى.

التحقق مقابل التعقيم

التحقق يرفض البيانات التي لا تستوفي المعايير. التعقيم (التنظيف) يعدّل البيانات بإزالة الأجزاء الخطرة أو تهريبها. على سبيل المثال، عند إدخال محتوى HTML، يمكن للتحقق فحص طول النص، بينما يقوم التعقيم بإزالة وسوم script عبر مكتبة HTML Purifier أو DOMPurify. التعقيم لا يحل محل التحقق: فهما يعملان معًا. التحقق سياسة "مسموح/ممنوع"، أما التعقيم فهو "تم التنظيف قبل الاستخدام".

أنواع التحقق من صحة الإدخال

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

التحقق من التنسيق

فحص نوع البيانات وحجمها وتنسيقها والأحرف المسموحة. يتم التنفيذ عبر التعبيرات النمطية والأنواع المدمجة في اللغات ومكتبات التحقق. أمثلة: فحص UUID (تنسيق 8-4-4-4-12 أرقام سداسية عشرية)، فحص رقم الهاتف (الأرقام فقط، + في البداية، من 7 إلى 15 حرفًا)، فحص العدد الصحيح (قيمة ضمن نطاق Integer.MIN_VALUE — Integer.MAX_VALUE). التحقق من التنسيق هو الحد الأدنى المطلوب لأي حقل إدخال.

التحقق الدلالي

فحص الصحة المنطقية للبيانات في سياق المجال. على سبيل المثال: تاريخ البداية ليس أحدث من تاريخ النهاية، العمر ضمن حدود معقولة للنظام، الإحداثيات ضمن منطقة الخدمة. يتطلب التحقق الدلالي فهم سياق العمل ولا يمكن إجراؤه بالاعتماد على التنسيق فقط. مثال: حقل "عدد التذاكر" قد ينجح في التحقق من التنسيق (عدد صحيح، > 0)، لكنه دلاليًا لا يمكن أن يتجاوز عدد المقاعد المتاحة.

التحقق من قواعد العمل

المستوى الأكثر تعقيدًا — فحص البيانات للتأكد من مطابقتها لقواعد عمل التطبيق. أمثلة: لا يمكن للمستخدم حذف المسؤول الوحيد، إجمالي الطلب لا يتجاوز حد الائتمان، يمكن طلب المنتج فقط إذا كان متوفرًا. غالبًا ما يتطلب التحقق من قواعد العمل استعلامات قاعدة البيانات أو الخدمات الخارجية ويتم بعد فحوصات التنسيق والدلالات. أخطاء قواعد العمل هي السبب الأكثر شيوعًا لاستياء المستخدمين.

التحقق في العميل وفي الخادم

التحقق في العميل (في المتصفح أو تطبيق الجوال) ضروري لراحة المستخدم: استجابة فورية دون إرسال البيانات إلى الخادم. ومع ذلك، فإن التحقق في الخادم هو الموثوق الوحيد، لأن كود العميل يمكن تجاوزه دائمًا. أرسل الطلبات عبر أدوات المطور أو Postman أو بروكسي (Burp Suite) — وسيختفي التحقق في العميل. وفقًا لـ PortSwigger Research (2025)، يعتمد أكثر من 90% من تطبيقات الويب المختبرة حصريًا على التحقق في العميل لحقل واحد على الأقل.

القاعدة: العميل لتجربة المستخدم، والخادم للأمان

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

تنفيذ التحقق في العميل

في الويب: سمات HTML5 (required، pattern، min/max، type="email") وJavaScript. في تطبيقات الجوال: مُدققات أصلية لحقول النص (InputFilter في Android، textField(:shouldChangeCharactersIn:) في iOS). React Hook Form وFormik لـ React، وVuelidate لـ Vue، وAngular Reactive Forms — مكتبات شائعة للتحقق في العميل. كلها تدعم القواعد المخصصة والتحقق غير المتزامن (فحص تفرد اسم المستخدم على الخادم).

// مثال على التحقق في الخادم باستخدام Express وJoi
const Joi = require('joi');

const userSchema = Joi.object({
    email: Joi.string()
        .email()
        .required()
        .max(255),
    age: Joi.number()
        .integer()
        .min(18)
        .max(120)
        .required(),
    password: Joi.string()
        .pattern(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,128}$/)
        .required()
});

app.post('/api/users', async (req, res) => {
    const { error, value } = userSchema.validate(req.body);
    if (error) {
        return res.status(400).json({
            error: error.details[0].message
        });
    }
    // value — بيانات تم التحقق منها وأصبحت آمنة
    const user = await User.create(value);
    res.status(201).json(user);
});

التحقق في تطبيقات الجوال

تفرض تطبيقات الجوال متطلبات خاصة على التحقق من البيانات. الشاشة أصغر — يجب أن تكون الأخطاء موجزة، ولوحة المفاتيح سياقية (رقمية لإدخال الأرقام)، والفحص غير متزامن حتى لا يحجب واجهة المستخدم. توفر المنصات الأصلية آليات تحقق مدمجة يجب استخدامها افتراضيًا. إرشادات Material Design لنظام Android وإرشادات Human Interface لنظام iOS تحتوي على توصيات مفصلة لعرض أخطاء التحقق.

التحقق على Android (Jetpack Compose)

يقدم Jetpack Compose نهجًا تصريحيًا للتحقق عبر إدارة الحالة. يرتبط كل حقل إدخال بحالة (MutableState)، ويُحسب الخطأ بناءً على القيمة الحالية. مكتبة Compose Validator تبسط إنشاء القواعد: required، email، min/max length، pattern. يتم تفعيل التحقق عند تغيير النص (onValueChange) أو عند محاولة إرسال النموذج. يُنصح بإظهار الخطأ فقط بعد أول إرسال أو بعد أن ينتهي المستخدم من الكتابة (debounce 300-500ms).

التحقق على iOS (SwiftUI)

لا يحتوي SwiftUI على آلية تحقق مدمجة للنماذج، لكنه يسمح بتنفيذها بسهولة عبر Combine وproperty wrappers. استخدم @State لقيمة الحقل وخاصية محسوبة للخطأ. يوفر إطار ValidatedPropertyKit مُزيّنات جاهزة: @Validated().email()، @Validated().range(18...120). توصية iOS — استخدام أنواع لوحة المفاتيح (UIKeyboardType.emailAddress، .numberPad) والكتابة التلقائية بأحرف كبيرة لتقليل عدد الأخطاء على مستوى الإدخال.

التحقق على Flutter

يوفر Flutter الفئة Form وTextFormField مع تحقق مدمج عبر استدعاء مُدقّق. يعيد كل حقل خطأً كسلسلة نصية أو null إذا كانت البيانات صحيحة. FormState.validate() يشغل فحص جميع حقول النموذج. حزمة reactive_forms للحالات المعقدة: مُدققات مخصصة، فحص غير متزامن، قواعد ديناميكية. يستخدم Flutter Web والنسخة المحمولة نفس API، مما يبسط الصيانة.

// مثال على التحقق من نموذج في Flutter
Form(
    key: _formKey,
    child: Column(
        children: [
            TextFormField(
                decoration: InputDecoration(labelText: 'Email'),
                validator: (value) {
                    if (value == null || value.isEmpty) {
                        return 'Email is required';
                    }
                    if (!RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$')
                            .hasMatch(value)) {
                        return 'Enter a valid email';
                    }
                    return null;
                },
            ),
            ElevatedButton(
                onPressed: () {
                    if (_formKey.currentState!.validate()) {
                        // معالجة البيانات الصالحة
                    }
                },
                child: Text('إرسال'),
            ),
        ],
    ),
)

تقنيات وأدوات التحقق

توفر الأطر الحديثة مُدققات مدمجة تغطي 80% من الاحتياجات. أما الـ 20% المتبقية فتتطلب قواعد مخصصة أو تعبيرات نمطية أو دمج القواعد الموجودة. المبدأ الأساسي هو أن يكون التحقق تصريحيًا بحيث يسهل قراءته واختباره وصيانته. تجنب منطق التحقق المنتشر عبر وحدات التحكم والشاشات — انقله إلى فئات أو مخططات منفصلة.

أساليب القائمة البيضاء مقابل القائمة السوداء

القائمة البيضاء — تحدد البيانات المسموحة، ويُرفض كل ما عداها. القائمة السوداء — تحدد البيانات الممنوعة، ويُسمح بكل ما عداها. القائمة البيضاء دائمًا أكثر موثوقية: تعرف بالضبط البيانات التي ستمر. تتطلب القائمة السوداء توقع جميع الهجمات الممكنة، وهو أمر مستحيل. مثال: عند فحص العمر، استخدم القائمة البيضاء (الأرقام من 18 إلى 120 فقط) بدلًا من القائمة السوداء (منع "0" و"-1" و"999999").

التعبيرات النمطية — القوة والخطر

التعبيرات النمطية أداة فعالة للتحقق من التنسيق، لكنها قد تكون مصدرًا لهجمات ReDoS (Regular Expression Denial of Service). بعض الأنماط (على سبيل المثال، (a+)+b) تؤدي إلى تراجع كارثي في السلاسل الطويلة، مما يحمّل معالج الخادم بالكامل. استخدم مكتبات regex مجربة وحدد طول السلسلة قبل تطبيق التعبير النمطي. للحالات المعقدة (البريد الإلكتروني، URL) استخدم المحللات المدمجة في اللغات بدلًا من التعبيرات النمطية المكتوبة يدويًا.

الأخطاء النموذجية في التحقق

حتى المطورون ذوو الخبرة يرتكبون أخطاء عند تنفيذ التحقق. الأكثر شيوعًا: التحقق في العميل فقط، قواعد صارمة جدًا (كلمة المرور "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters")، رسائل خطأ غير مفيدة ("Error: invalid input") وتجاهل الحالات الحدية (المسافات في البداية/النهاية، أحرف Unicode، سلاسل فارغة). كل من هذه الأخطاء يضعف تجربة المستخدم وقد يقلل معدل تحويل النماذج.

• التحقق في العميل فقط — أخطر خطأ: يمكن تزوير أي طلب عبر Postman أو cURL
• قواعد صارمة جدًا — تنفر المستخدمين: توصي OWASP بمتطلبات دنيا عند التسجيل
• تجاهل Unicode — فحص طول السلسلة بالبايت (وليس بالأحرف) يكسر الروسية والصينية والإيموجي
• أخطاء غير مفيدة — "Invalid format" بدلًا من "Email must contain @ symbol after local part"
• فحص الحقل الفارغ — if (value) لا يميز السلسلة الفارغة عن الصفر أو false أو "0"

أفضل ممارسة هي نظام مركزي للتحقق تغطيه اختبارات الوحدة. يجب اختبار كل قاعدة على حدة: القيم الحدية، البيانات الصحيحة، الهجمات النموذجية (محاولات SQLi، حمولات XSS، سلاسل طويلة جدًا). اختبارات الانحدار على التحقق تمنع إضعاف القواعد عرضيًا أثناء إعادة الهيكلة. استخدم الاختبار القائم على الخصائص (QuickCheck، fast-check) لتوليد بيانات عشوائية والتحقق من أن التحقق لا يفشل بخطأ.