मोबाइल ऐप्लिकेशन में इनपुट सत्यापन — मूल बातें, जाँच के तरीके और कार्यान्वयन

इनपुट सत्यापन क्या है?

इनपुट सत्यापन यह जाँच है कि उपयोगकर्ता, बाहरी सेवा या किसी अन्य घटक से ऐप्लिकेशन में आने वाला डेटा अपेक्षित मानदंडों के अनुरूप है या नहीं। इन मानदंडों में डेटा प्रकार (स्ट्रिंग, संख्या, तिथि), फ़ॉर्मेट (ईमेल, 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 सामग्री इनपुट करते समय सत्यापन टेक्स्ट की लंबाई जाँच सकता है, जबकि सैनिटाइज़ेशन 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 और 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% के लिए कस्टम नियम, रेगुलर एक्सप्रेशन या मौजूदा नियमों की रचना की आवश्यकता होती है। मुख्य सिद्धांत यह है कि सत्यापन घोषणात्मक होना चाहिए ताकि इसे आसानी से पढ़ा, परीक्षण और बनाए रखा जा सके। कंट्रोलरों और स्क्रीनों में फैली सत्यापन लॉजिक से बचें — इसे अलग क्लास या स्कीमा में रखें।

White-list vs Black-list दृष्टिकोण

श्वेत सूची (white-list) — आप परिभाषित करते हैं कि कौन सा डेटा अनुमत है, बाकी सब अस्वीकार किया जाता है। काली सूची (black-list) — आप परिभाषित करते हैं कि कौन सा डेटा निषिद्ध है, बाकी सब पारित होता है। श्वेत सूची हमेशा अधिक विश्वसनीय होती है: आप ठीक-ठीक जानते हैं कि कौन सा डेटा पारित होगा। काली सूची के लिए सभी संभावित हमलों का पूर्वानुमान आवश्यक है, जो असंभव है। उदाहरण: उम्र की जाँच करते समय श्वेत सूची का उपयोग करें (केवल 18 से 120 तक की संख्याएँ), काली सूची का नहीं ("0", "-1", "999999" निषिद्ध करें)।

रेगुलर एक्सप्रेशन — शक्ति और खतरा

रेगुलर एक्सप्रेशन फ़ॉर्मेट सत्यापन के लिए प्रभावी टूल हैं, लेकिन वे 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") और edge-केसों की अनदेखी (शुरुआत/अंत में स्थान, Unicode अक्षर, खाली स्ट्रिंग्स)। इनमें से प्रत्येक गलती UX को खराब करती है और फ़ॉर्म रूपांतरण को कम कर सकती है।

• केवल क्लाइंट-साइड सत्यापन — सबसे खतरनाक गलती: Postman या cURL के माध्यम से किसी भी अनुरोध को जाली बनाया जा सकता है
• अत्यधिक सख्त नियम — उपयोगकर्ताओं को दूर भगाते हैं: OWASP पंजीकरण के समय न्यूनतम आवश्यकताओं की अनुशंसा करता है
• Unicode की अनदेखी — बाइट्स (अक्षरों में नहीं) में स्ट्रिंग की लंबाई जाँचने से रूसी, चीनी, इमोजी टूट जाते हैं
• जानकारीहीन त्रुटियाँ — "Invalid format" के बजाय "Email must contain @ symbol after local part"
• खाली फ़ील्ड जाँच — if (value) खाली स्ट्रिंग को शून्य, false या "0" से अलग नहीं करता

सर्वोत्तम अभ्यास unit-परीक्षणों द्वारा कवर की गई केंद्रीकृत सत्यापन प्रणाली है। प्रत्येक नियम का अलग-अलग परीक्षण किया जाना चाहिए: सीमा मान, सही डेटा, सामान्य हमले (SQLi प्रयास, XSS payloads, बहुत लंबी स्ट्रिंग्स)। सत्यापन पर रिग्रेशन परीक्षण रीफ़ैक्टरिंग के दौरान नियमों के आकस्मिक कमजोर होने से रोकते हैं। यादृच्छिक डेटा उत्पन्न करने और यह सत्यापित करने के लिए property-based परीक्षण (QuickCheck, fast-check) का उपयोग करें कि सत्यापन अपवाद के साथ विफल नहीं होता।