মোবাইল অ্যাপে ইনপুট ভ্যালিডেশন — মূল বিষয়, যাচাইয়ের পদ্ধতি এবং বাস্তবায়ন

ইনপুট ভ্যালিডেশন কী?

ইনপুট ভ্যালিডেশন হলো এই যাচাই যে ব্যবহারকারী, বাহ্যিক পরিষেবা বা অন্য কোনো উপাদান থেকে অ্যাপ্লিকেশনে আগত ডেটা প্রত্যাশিত মানদণ্ডের সাথে সামঞ্জস্যপূর্ণ কিনা। এই মানদণ্ডগুলোর মধ্যে রয়েছে ডেটার ধরন (স্ট্রিং, সংখ্যা, তারিখ), ফরম্যাট (ইমেইল, 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") এবং এজ-কেস উপেক্ষা (শুরু/শেষে স্পেস, Unicode অক্ষর, খালি স্ট্রিং)। এই ভুলগুলোর প্রতিটি UX খারাপ করে এবং ফর্ম কনভার্সন কমাতে পারে।

• শুধু ক্লায়েন্ট-সাইড ভ্যালিডেশন — সবচেয়ে বিপজ্জনক ভুল: Postman বা cURL দিয়ে যেকোনো অনুরোধ জাল করা যায়
• অত্যধিক কঠোর নিয়ম — ব্যবহারকারীদের দূরে সরিয়ে দেয়: OWASP নিবন্ধনের সময় সর্বনিম্ন প্রয়োজনীয়তার সুপারিশ করে
• Unicode উপেক্ষা — বাইটে (অক্ষরে নয়) স্ট্রিংয়ের দৈর্ঘ্য যাচাই রাশিয়ান, চীনা, ইমোজি ভেঙে দেয়
• তথ্যহীন ত্রুটি — "Invalid format" এর পরিবর্তে "Email must contain @ symbol after local part"
• খালি ফিল্ড যাচাই — if (value) খালি স্ট্রিংকে শূন্য, false বা "0" থেকে আলাদা করে না

সেরা অনুশীলন হলো ইউনিট পরীক্ষা দ্বারা আচ্ছাদিত একটি কেন্দ্রীভূত ভ্যালিডেশন সিস্টেম। প্রতিটি নিয়ম আলাদাভাবে পরীক্ষা করা উচিত: সীমার মান, সঠিক ডেটা, সাধারণ আক্রমণ (SQLi প্রচেষ্টা, XSS payloads, খুব দীর্ঘ স্ট্রিং)। ভ্যালিডেশনের উপর রিগ্রেশন পরীক্ষা রিফ্যাক্টরিংয়ের সময় নিয়মের আকস্মিক দুর্বলতা প্রতিরোধ করে। র্যান্ডম ডেটা তৈরি করতে এবং ভ্যালিডেশন ব্যতিক্রমে ব্যর্থ না হয় তা যাচাই করতে প্রপার্টি-বেইজড পরীক্ষা (QuickCheck, fast-check) ব্যবহার করুন।