موبائل ایپس میں ان پٹ توثیق — بنیادی باتیں، جانچ کے طریقے اور نفاذ

ان پٹ توثیق کیا ہے؟

ان پٹ توثیق یہ جانچ ہے کہ صارف، بیرونی سروس یا کسی اور جزو سے ایپلیکیشن میں آنے والا ڈیٹا متوقع معیاروں پر پورا اترتا ہے یا نہیں۔ ان معیاروں میں ڈیٹا کی قسم (سٹرنگ، نمبر، تاریخ)، فارمیٹ (ای میل، 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 سیکورٹی ماڈل میں دفاع کی پہلی لائن ہے: یہ غلط ڈیٹا کو سسٹم کے دوسرے اجزاء تک پہنچنے سے پہلے روک دیتی ہے۔

توثیق بمقابلہ صاف کرنا

توثیق ان ڈیٹا کو مسترد کرتی ہے جو معیاروں پر پورا نہیں اترتے۔ صاف کرنا (صفائی) خطرناک حصوں کو ہٹا کر یا escape کر کے ڈیٹا میں تبدیلی کرتا ہے۔ مثال کے طور پر، HTML مواد داخل کرتے وقت توثیق متن کی لمبائی چیک کر سکتی ہے، جبکہ صاف کرنا HTML Purifier یا DOMPurify لائبریری کے ذریعے script ٹیگز ہٹا سکتا ہے۔ صاف کرنا توثیق کی جگہ نہیں لیتا: دونوں مل کر کام کرتے ہیں۔ توثیق "مجاز/ممنوع" پالیسی ہے، جبکہ صاف کرنا "استعمال سے پہلے صاف شدہ" ہے۔

ان پٹ توثیق کی اقسام

توثیق کو جانچ کی گہرائی کے مطابق درجہ بند کیا جاتا ہے۔ فارمیٹ توثیق سب سے آسان اور تیز ہے، جبکہ بزنس توثیق سب سے پیچیدہ اور سیاق و سباق پر منحصر ہے۔ تینوں سطحوں کو ترتیب سے لاگو کیا جانا چاہیے: پہلے فارمیٹ، پھر سیمانٹکس، پھر بزنس منطق۔ کسی بھی سطح کو چھوڑنا سسٹم کے غلط کام یا کمزوریوں کا سبب بن سکتا ہے۔

فارمیٹ توثیق

ڈیٹا کی قسم، سائز، فارمیٹ اور مجاز حروف کی جانچ۔ اسے ریگولر ایکسپریشنز، زبانوں کے بلٹ ان اقسام اور توثیق لائبریریوں کے ذریعے لاگو کیا جاتا ہے۔ مثالیں: UUID کی جانچ (8-4-4-4-12 ہیکسا ڈیسیمل ہندسوں کا فارمیٹ)، فون نمبر کی جانچ (صرف ہندسے، شروع میں +، 7 سے 15 حروف)، عدد کی جانچ (Integer.MIN_VALUE — Integer.MAX_VALUE حد کے اندر قدر)۔ فارمیٹ توثیق کسی بھی ان پٹ فیلڈ کے لیے کم از کم مطلوبہ سطح ہے۔

سیمانٹک توثیق

ڈومین کے سیاق و سباق میں ڈیٹا کی منطقی درستگی کی جانچ۔ مثال کے طور پر: آغاز کی تاریخ اختتام کی تاریخ سے بعد کی نہیں، عمر سسٹم کے لیے معقول حد کے اندر، نقاط سروس کے علاقے میں۔ سیمانٹک توثیق کے لیے بزنس سیاق و سباق کی سمجھ ضروری ہے اور یہ صرف فارمیٹ کی بنیاد پر نہیں کی جا سکتی۔ مثال: "ٹکٹوں کی تعداد" فیلڈ فارمیٹ توثیق پاس کر سکتی ہے (عدد، > 0)، لیکن سیمانٹک طور پر دستیاب نشستوں کی تعداد سے زیادہ نہیں ہو سکتی۔

بزنس توثیق

سب سے پیچیدہ سطح — ایپلیکیشن کے بزنس قواعد کے مطابق ڈیٹا کی جانچ۔ مثالیں: صارف واحد ایڈمن کو حذف نہیں کر سکتا، آرڈر کی رقم کریڈٹ کی حد سے زیادہ نہیں، پروڈکٹ صرف اسٹاک میں ہونے پر ہی آرڈر کی جا سکتی ہے۔ بزنس توثیق کے لیے اکثر ڈیٹا بیس کوئریز یا بیرونی خدمات کی ضرورت ہوتی ہے اور یہ فارمیٹ اور سیمانٹک جانچ کے بعد کی جاتی ہے۔ بزنس توثیق کی غلطیاں صارفین کی عدم اطمینان کی سب سے عام وجہ ہیں۔

کلائنٹ اور سرور سائیڈ توثیق

کلائنٹ سائیڈ توثیق (براؤزر یا موبائل ایپ میں) صارف کی سہولت کے لیے ضروری ہے: ڈیٹا کو سرور پر بھیجے بغیر فوری رائے۔ تاہم، سرور سائیڈ توثیق ہی واحد قابل اعتماد ہے، کیونکہ کلائنٹ کوڈ کو ہمیشہ نظرانداز کیا جا سکتا ہے۔ ڈویلپر ٹولز، Postman یا پراکسی (Burp Suite) کے ذریعے درخواستیں بھیجیں — اور کلائنٹ سائیڈ توثیق ختم ہو جاتی ہے۔ PortSwigger Research (2025) کے مطابق، آزمائے گئے ویب ایپلیکیشنز میں سے 90% سے زیادہ کم از کم ایک فیلڈ کے لیے صرف کلائنٹ سائیڈ توثیق پر انحصار کرتی ہیں۔

قاعدہ: کلائنٹ UX کے لیے، سرور سیکورٹی کے لیے

کلائنٹ سائیڈ توثیق جمع کرانے کا بٹن غیر فعال کر سکتی ہے، غلطیوں کو نمایاں کر سکتی ہے اور اشارے دکھا سکتی ہے۔ سرور سائیڈ توثیق ہر پیرامیٹر کی لازمی جانچ ہے، چاہے کلائنٹ نے اسے پہلے ہی چیک کر لیا ہو۔ دونوں سطحوں پر توثیق کو دہرانا معیاری عمل ہے۔ سرور کو ڈیٹا کی جانچ ایسے کرنی چاہیے جیسے کلائنٹ کا وجود ہی نہ ہو۔ یہ تبدیل شدہ درخواستوں، خودکار حملوں اور نقصان دہ کلائنٹس سے تحفظ کی ضمانت دیتا ہے۔

کلائنٹ سائیڈ توثیق کا نفاذ

ویب پر — HTML5 صفات (required, pattern, min/max, type="email") اور JavaScript۔ موبائل ایپس میں — ٹیکسٹ فیلڈز کے نیٹوو ویلڈیٹر (Android میں InputFilter، iOS میں textField(:shouldChangeCharactersIn:))۔ React کے لیے React Hook Form اور Formik، Vue کے لیے Vuelidate، 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);
});

موبائل ایپس میں توثیق

موبائل ایپلیکیشنز ڈیٹا توثیق پر خصوصی تقاضے عائد کرتی ہیں۔ اسکرین چھوٹی ہوتی ہے — غلطیاں مختصر ہونی چاہئیں، کی بورڈ سیاق و سباق کے مطابق (نمبر داخل کرنے کے لیے عددی) اور جانچ غیر متزامن ہونی چاہیے تاکہ UI بلاک نہ ہو۔ نیٹوو پلیٹ فارمز بلٹ ان توثیق میکانزم فراہم کرتے ہیں جنہیں بطور ڈیفالٹ استعمال کیا جانا چاہیے۔ Android کے لیے Material Design Guidelines اور iOS کے لیے Human Interface Guidelines میں توثیق کی غلطیوں کو ظاہر کرنے کے تفصیلی مشورے شامل ہیں۔

Android پر توثیق (Jetpack Compose)

Jetpack Compose سٹیٹ مینجمنٹ کے ذریعے توثیق کا اعلانیہ طریقہ فراہم کرتا ہے۔ ہر ان پٹ فیلڈ ایک سٹیٹ (MutableState) سے منسلک ہوتا ہے، اور غلطی کا حساب موجودہ قدر کی بنیاد پر کیا جاتا ہے۔ Compose Validator لائبریری قواعد بنانا آسان بناتی ہے: required, email, min/max length, pattern۔ توثیق متن کی تبدیلی (onValueChange) یا فارم جمع کرانے کی کوشش پر چالو ہوتی ہے۔ غلطی کو صرف پہلی جمع آوری کے بعد یا صارف کے ٹائپنگ مکمل کرنے کے بعد دکھانے کی سفارش کی جاتی ہے (debounce 300-500ms)۔

iOS پر توثیق (SwiftUI)

SwiftUI میں فارم توثیق کا بلٹ ان میکانزم نہیں ہے، لیکن اسے Combine اور پراپرٹی ریپرز کے ذریعے آسانی سے لاگو کیا جا سکتا ہے۔ فیلڈ کی قدر کے لیے @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% کے لیے حسب ضرورت قواعد، ریگولر ایکسپریشنز یا موجودہ قواعد کی ترکیب کی ضرورت ہوتی ہے۔ کلیدی اصول یہ ہے کہ توثیق اعلانیہ ہونی چاہیے تاکہ اسے آسانی سے پڑھا، جانچا اور برقرار رکھا جا سکے۔ کنٹرولرز اور اسکرینز پر بکھری ہوئی توثیق منطق سے گریز کریں — اسے علیحدہ کلاسز یا اسکیموں میں منتقل کریں۔

White-list vs Black-list طریقے

سفید فہرست (white-list) — آپ طے کرتے ہیں کہ کون سا ڈیٹا مجاز ہے؛ باقی سب مسترد کیا جاتا ہے۔ کالی فہرست (black-list) — آپ طے کرتے ہیں کہ کون سا ڈیٹا ممنوع ہے؛ باقی سب منظور کیا جاتا ہے۔ سفید فہرست ہمیشہ زیادہ قابل اعتماد ہوتی ہے: آپ کو معلوم ہوتا ہے کہ کون سا ڈیٹا منظور ہوگا۔ کالی فہرست کے لیے تمام ممکنہ حملوں کا اندازہ لگانا ضروری ہے، جو ناممکن ہے۔ مثال: عمر کی جانچ کرتے وقت کالی فہرست ("0", "-1", "999999" ممنوع) کے بجائے سفید فہرست استعمال کریں (صرف 18 سے 120 تک کے نمبر)۔

ریگولر ایکسپریشنز — طاقت اور خطرہ

ریگولر ایکسپریشنز فارمیٹ توثیق کے لیے موثر آلہ ہیں، لیکن یہ ReDoS حملوں (Regular Expression Denial of Service) کا ذریعہ بن سکتے ہیں۔ کچھ پیٹرن (مثال کے طور پر، (a+)+b) لمبی سٹرنگز پر تباہ کن بیک ٹریکنگ کا باعث بنتے ہیں اور سرور کے CPU کو مکمل طور پر لوڈ کر دیتے ہیں۔ آزمودہ regex لائبریریاں استعمال کریں اور ریگولر ایکسپریشن لگانے سے پہلے سٹرنگ کی لمبائی محدود کریں۔ پیچیدہ صورتوں (ای میل, URL) کے لیے خود بنائے گئے ریگولر ایکسپریشن کے بجائے زبانوں کے بلٹ ان پارسر استعمال کریں۔

توثیق میں عام غلطیاں

تجربہ کار ڈویلپرز بھی توثیق کے نفاذ میں غلطیاں کرتے ہیں۔ سب سے عام: صرف کلائنٹ پر توثیق، بہت سخت قواعد (پاس ورڈ "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters")، غیر معلوماتی غلطی کے پیغامات ("Error: invalid input") اور ایج کیسز کو نظرانداز کرنا (شروع/آخر میں خالی جگہیں، Unicode حروف، خالی سٹرنگز)۔ ان میں سے ہر غلطی UX کو خراب کرتی ہے اور فارم کی تبدیلی کو کم کر سکتی ہے۔

• صرف کلائنٹ سائیڈ توثیق — سب سے خطرناک غلطی: کوئی بھی درخواست Postman یا cURL سے جعلی بنائی جا سکتی ہے
• بہت سخت قواعد — صارفین کو بھگا دیتے ہیں: OWASP رجسٹریشن کے وقت کم از کم تقاضوں کی سفارش کرتا ہے
• Unicode کو نظرانداز کرنا — سٹرنگ کی لمبائی حروف میں نہیں بائیٹس میں چیک کرنا روسی، چینی اور ایموجی کو توڑ دیتا ہے
• غیر معلوماتی غلطیاں — "Email must contain @ symbol after local part" کے بجائے "Invalid format"
• خالی فیلڈ کی جانچ — if (value) خالی سٹرنگ کو صفر، false یا "0" سے الگ نہیں کرتا

بہترین عمل ایک مرکزی توثیق نظام ہے جو یونٹ ٹیسٹوں سے ڈھکا ہوا ہو۔ ہر قاعدہ کو الگ سے جانچا جانا چاہیے: حدود کی قدریں، درست ڈیٹا، عام حملے (SQLi کوششیں، XSS payloads، بہت لمبی سٹرنگز)۔ توثیق پر ریگریشن ٹیسٹ ریفیکٹرنگ کے دوران قواعد کے حادثاتی کمزور ہونے سے روکتے ہیں۔ بے ترتیب ڈیٹا پیدا کرنے اور یہ جانچنے کے لیے پراپرٹی بیسڈ ٹیسٹنگ (QuickCheck, fast-check) استعمال کریں کہ توثیق مستثنیٰ کے ساتھ ناکام نہیں ہوتی۔