اعتبارسنجی داده‌های ورودی در برنامه‌های موبایل — مبانی، روش‌های بررسی و پیاده‌سازی

اعتبارسنجی داده‌های ورودی چیست؟

اعتبارسنجی داده‌های ورودی بررسی این است که داده‌هایی که از سوی کاربر، سرویس خارجی یا مؤلفه دیگر وارد برنامه می‌شوند، با معیارهای مورد انتظار مطابقت داشته باشند. این معیارها شامل نوع داده (رشته، عدد، تاریخ)، قالب (ایمیل، URL، تلفن)، محدوده مقادیر (سن از ۱۸ تا ۱۲۰)، طول (رمز عبور از ۸ تا ۱۲۸ کاراکتر) و کاراکترهای مجاز (فقط حروف لاتین، ارقام، خط تیره) است. بدون اعتبارسنجی، برنامه ممکن است داده‌هایی را پردازش کند که باعث خطاهای اجرا، خرابی داده‌ها یا آسیب‌پذیری‌های امنیتی می‌شوند.

چرا اعتبارسنجی عنصری حیاتی در امنیت است؟

نبود اعتبارسنجی داده‌های ورودی علت ریشه‌ای آسیب‌پذیری‌هایی مانند SQL Injection، XSS، Command Injection، Path Traversal و Buffer Overflow است. طبق MITRE CWE (2025)، CWE-20 (Improper Input Validation) رتبه دوم را در فهرست خطرناک‌ترین خطاهای نرم‌افزاری دارد. اعتبارسنجی اولین خط دفاعی در مدل امنیتی Defense in Depth است: داده‌های نامعتبر را پیش از رسیدن به سایر مؤلفه‌های سیستم قطع می‌کند.

اعتبارسنجی در برابر پاک‌سازی

اعتبارسنجی داده‌هایی را که با معیارها مطابقت ندارند رد می‌کند. پاک‌سازی (تمیزسازی) با حذف یا escape کردن بخش‌های خطرناک، داده‌ها را تغییر می‌دهد. برای مثال، هنگام ورود محتوای HTML، اعتبارسنجی می‌تواند طول متن را بررسی کند و پاک‌سازی تگ‌های script را با کتابخانه HTML Purifier یا DOMPurify حذف کند. پاک‌سازی جایگزین اعتبارسنجی نمی‌شود: آن‌ها با هم کار می‌کنند. اعتبارسنجی سیاست «مجاز/ممنوع» است و پاک‌سازی «تمیز شده پیش از استفاده» است.

انواع اعتبارسنجی داده‌های ورودی

اعتبارسنجی بر اساس عمق بررسی طبقه‌بندی می‌شود. اعتبارسنجی فرمتی ساده‌ترین و سریع‌ترین است و اعتبارسنجی تجاری پیچیده‌ترین و وابسته‌ترین به زمینه است. هر سه سطح باید به ترتیب اعمال شوند: ابتدا قالب، سپس معنا و سپس منطق تجاری. حذف هر سطح می‌تواند به عملکرد نادرست سیستم یا آسیب‌پذیری منجر شود.

اعتبارسنجی فرمتی

بررسی نوع داده، اندازه، قالب و کاراکترهای مجاز. از طریق عبارات منظم، انواع داخلی زبان‌ها و کتابخانه‌های اعتبارسنجی پیاده‌سازی می‌شود. مثال‌ها: بررسی UUID (قالب ۸-۴-۴-۴-۱۲ رقم هگزادسیمال)، بررسی شماره تلفن (فقط ارقام، + در ابتدا، از ۷ تا ۱۵ کاراکتر)، بررسی عدد صحیح (مقدار در محدوده Integer.MIN_VALUE — Integer.MAX_VALUE). اعتبارسنجی فرمتی حداقل سطح لازم برای هر فیلد ورودی است.

اعتبارسنجی معنایی

بررسی درستی منطقی داده‌ها در زمینه حوزه موضوعی. برای مثال: تاریخ شروع دیرتر از تاریخ پایان نیست، سن در محدوده معقول برای سیستم است، مختصات در منطقه خدمات‌رسانی است. اعتبارسنجی معنایی نیازمند درک زمینه تجاری است و فقط بر اساس قالب قابل انجام نیست. مثال: فیلد «تعداد بلیت» ممکن است از بررسی فرمتی عبور کند (عدد صحیح، > ۰)، اما از نظر معنایی نمی‌تواند از تعداد صندلی‌های خالی بیشتر باشد.

اعتبارسنجی تجاری

پیچیده‌ترین سطح — بررسی داده‌ها از نظر تطابق با قوانین تجاری برنامه. مثال‌ها: کاربر نمی‌تواند تنها مدیر را حذف کند، مبلغ سفارش از سقف اعتبار بیشتر نیست، محصول فقط در صورت موجود بودن قابل سفارش است. اعتبارسنجی تجاری اغلب به پرس‌وجوهای پایگاه داده یا سرویس‌های خارجی نیاز دارد و پس از بررسی‌های فرمتی و معنایی انجام می‌شود. خطاهای اعتبارسنجی تجاری رایج‌ترین دلیل نارضایتی کاربران هستند.

اعتبارسنجی سمت کلاینت و سرور

اعتبارسنجی سمت کلاینت (در مرورگر یا برنامه موبایل) برای راحتی کاربر لازم است: بازخورد فوری بدون ارسال داده به سرور. اما اعتبارسنجی سمت سرور تنها روش مطمئن است، زیرا کد کلاینت همیشه قابل دور زدن است. درخواست‌ها را از طریق ابزارهای توسعه‌دهنده، Postman یا پروکسی (Burp Suite) ارسال کنید — و اعتبارسنجی سمت کلاینت از بین می‌رود. طبق PortSwigger Research (2025)، بیش از ۹۰٪ از برنامه‌های وب آزمایش‌شده برای حداقل یک فیلد منحصراً به اعتبارسنجی سمت کلاینت تکیه می‌کنند.

قانون: کلاینت برای UX، سرور برای امنیت

اعتبارسنجی سمت کلاینت می‌تواند دکمه ارسال را غیرفعال کند، خطاها را برجسته کند، راهنماها را نشان دهد. اعتبارسنجی سمت سرور بررسی اجباری هر پارامتر است، حتی اگر کلاینت قبلاً آن را بررسی کرده باشد. تکرار اعتبارسنجی در هر دو سطح یک رویه استاندارد است. سرور باید داده‌ها را طوری بررسی کند که گویی کلاینتی وجود ندارد. این امر محافظت در برابر درخواست‌های تغییر یافته، حملات خودکار و کلاینت‌های مخرب را تضمین می‌کند.

پیاده‌سازی اعتبارسنجی سمت کلاینت

در وب — ویژگی‌های HTML5 (required، pattern، min/max، type="email") و جاوااسکریپت. در برنامه‌های موبایل — اعتبارسنج‌های بومی فیلدهای متنی (InputFilter در اندروید، 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 Guidelines برای اندروید و Human Interface Guidelines برای iOS توصیه‌های مفصلی درباره نمایش خطاهای اعتبارسنجی دارند.

اعتبارسنجی در اندروید (Jetpack Compose)

Jetpack Compose رویکرد اعلانی به اعتبارسنجی از طریق مدیریت وضعیت ارائه می‌دهد. هر فیلد ورودی به وضعیت (MutableState) متصل است و خطا بر اساس مقدار فعلی محاسبه می‌شود. کتابخانه Compose Validator ایجاد قوانین را ساده می‌کند: required، email، min/max length، pattern. اعتبارسنجی هنگام تغییر متن (onValueChange) یا هنگام تلاش برای ارسال فرم فعال می‌شود. توصیه می‌شود خطا فقط پس از اولین ارسال یا پس از پایان ورود کاربر (debounce ۳۰۰-۵۰۰ms) نمایش داده شود.

اعتبارسنجی در iOS (SwiftUI)

SwiftUI مکانیزم داخلی اعتبارسنجی فرم ندارد، اما امکان پیاده‌سازی آسان آن از طریق Combine و property wrappers را فراهم می‌کند. برای مقدار فیلد از @State و برای خطا از یک ویژگی محاسبه‌شده استفاده کنید. فریم‌ورک ValidatedPropertyKit دکوراتورهای آماده ارائه می‌دهد: @Validated().email()، @Validated().range(18...120). توصیه iOS — از انواع صفحه‌کلید (UIKeyboardType.emailAddress، .numberPad) و auto-capitalization برای کاهش خطاها در سطح ورود استفاده کنید.

اعتبارسنجی در Flutter

Flutter کلاس Form و TextFormField را با اعتبارسنجی داخلی از طریق callback اعتبارسنج ارائه می‌دهد. هر فیلد خطا را به‌صورت رشته یا در صورت درست بودن داده‌ها 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()) {
                        // Process valid data
                    }
                },
                child: Text('Submit'),
            ),
        ],
    ),
)

تکنیک‌ها و ابزارهای اعتبارسنجی

فریم‌ورک‌های مدرن اعتبارسنج‌های داخلی ارائه می‌دهند که ۸۰٪ نیازها را پوشش می‌دهند. ۲۰٪ باقی‌مانده به قوانین سفارشی، عبارات منظم یا ترکیب موارد موجود نیاز دارد. اصل کلیدی — اعتبارسنجی باید اعلانی باشد تا بتوان به‌راحتی آن را خواند، آزمایش کرد و نگهداری کرد. از منطق اعتبارسنجی پراکنده در کنترلرها و صفحه‌ها اجتناب کنید — آن را در کلاس‌ها یا طرح‌های جداگانه قرار دهید.

رویکردهای فهرست سفید در برابر فهرست سیاه

فهرست سفید — مشخص می‌کنید کدام داده‌ها مجازند، بقیه رد می‌شوند. فهرست سیاه — مشخص می‌کنید کدام داده‌ها ممنوعند، بقیه عبور می‌کنند. فهرست سفید همیشه مطمئن‌تر است: دقیقاً می‌دانید کدام داده‌ها عبور می‌کنند. فهرست سیاه نیاز به پیش‌بینی همه حملات ممکن دارد که غیرممکن است. مثال: هنگام بررسی سن از فهرست سفید استفاده کنید (فقط اعداد ۱۸ تا ۱۲۰)، نه فهرست سیاه (منع «۰»، «‎-۱»، «۹۹۹۹۹۹»).

عبارات منظم — قدرت و خطر

عبارات منظم ابزاری مؤثر برای اعتبارسنجی فرمتی هستند، اما می‌توانند منبع حملات ReDoS (Regular Expression Denial of Service) باشند. برخی الگوها (برای مثال (a+)+b) در رشته‌های طولانی باعث backtracking فاجعه‌بار می‌شوند و CPU سرور را کاملاً اشغال می‌کنند. از کتابخانه‌های regex آزموده‌شده استفاده کنید و قبل از اعمال عبارت منظم طول رشته را محدود کنید. برای موارد پیچیده (ایمیل، URL) از parserهای داخلی زبان‌ها استفاده کنید، نه عبارت منظم دست‌ساز.

خطاهای رایج در اعتبارسنجی

حتی توسعه‌دهندگان باتجربه در پیاده‌سازی اعتبارسنجی خطا می‌کنند. رایج‌ترین‌ها: اعتبارسنجی فقط در سمت کلاینت، قوانین بیش از حد سخت‌گیرانه (رمز عبور «Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters»)، پیام‌های خطای غیراطلاع‌رسان ("Error: invalid input") و نادیده گرفتن موارد مرزی (فاصله در ابتدا/انتها، کاراکترهای یونیکد، رشته‌های خالی). هر یک از این خطاها UX را بدتر می‌کند و می‌تواند نرخ تبدیل فرم‌ها را کاهش دهد.

• فقط اعتبارسنجی سمت کلاینت — خطرناک‌ترین خطا: هر درخواستی را می‌توان با Postman یا cURL جعل کرد
• قوانین بیش از حد سخت‌گیرانه — کاربران را فراری می‌دهد: OWASP حداقل الزامات را در ثبت‌نام توصیه می‌کند
• نادیده گرفتن یونیکد — بررسی طول رشته به بایت (نه به کاراکتر) فارسی، چینی و ایموجی را خراب می‌کند
• خطاهای غیراطلاع‌رسان — «Invalid format» به جای «Email must contain @ symbol after local part»
• بررسی فیلد خالی — if (value) رشته خالی را از صفر، false یا «۰» تشخیص نمی‌دهد

بهترین روش — سیستم اعتبارسنجی متمرکز پوشیده‌شده با تست‌های واحد. هر قانون باید جداگانه آزمایش شود: مقادیر مرزی، داده‌های درست، حملات رایج (تلاش‌های SQLi، XSS-payloads، رشته‌های بسیار طولانی). تست‌های بازگشتی روی اعتبارسنجی از تضعیف تصادفی قوانین در هنگام بازسازی جلوگیری می‌کنند. از property-based testing (QuickCheck، fast-check) برای تولید داده‌های تصادفی و بررسی اینکه اعتبارسنجی با استثنا سقوط نمی‌کند، استفاده کنید.