Kiểm tra dữ liệu đầu vào trong ứng dụng di động — kiến thức cơ bản, phương pháp kiểm tra và triển khai

Kiểm tra dữ liệu đầu vào là gì?

Kiểm tra dữ liệu đầu vào là việc xác minh dữ liệu đi vào ứng dụng từ người dùng, dịch vụ bên ngoài hoặc thành phần khác đáp ứng các tiêu chí mong đợi. Các tiêu chí này bao gồm loại dữ liệu (chuỗi, số, ngày tháng), định dạng (email, URL, điện thoại), phạm vi giá trị (tuổi từ 18 đến 120), độ dài (mật khẩu từ 8 đến 128 ký tự) và ký tự được phép (chỉ chữ Latinh, chữ số, dấu gạch ngang). Nếu không kiểm tra, ứng dụng có thể xử lý dữ liệu gây ra lỗi thực thi, hỏng dữ liệu hoặc lỗ hổng bảo mật.

Tại sao kiểm tra là yếu tố bảo mật quan trọng?

Việc thiếu kiểm tra dữ liệu đầu vào là nguyên nhân gốc rễ của các lỗ hổng như SQL Injection, XSS, Command Injection, Path Traversal và Buffer Overflow. Theo MITRE CWE (2025), CWE-20 (Improper Input Validation) đứng thứ hai trong bảng xếp hạng các lỗi phần mềm nguy hiểm nhất. Kiểm tra là tuyến phòng thủ đầu tiên trong mô hình bảo mật Defense in Depth: nó chặn dữ liệu không hợp lệ trước khi chúng đến được các thành phần khác của hệ thống.

Kiểm tra vs Làm sạch

Kiểm tra từ chối dữ liệu không đạt tiêu chí. Làm sạch (vệ sinh) sửa đổi dữ liệu bằng cách loại bỏ hoặc thoát các phần nguy hiểm. Ví dụ, khi nhập nội dung HTML, kiểm tra có thể xác minh độ dài văn bản, còn làm sạch loại bỏ thẻ script qua thư viện HTML Purifier hoặc DOMPurify. Làm sạch không thay thế kiểm tra: chúng hoạt động cùng nhau. Kiểm tra là chính sách "cho phép/cấm", còn làm sạch là "đã vệ sinh trước khi sử dụng".

Các loại kiểm tra dữ liệu đầu vào

Kiểm tra được phân loại theo độ sâu của quá trình xác minh. Kiểm tra định dạng là đơn giản và nhanh nhất, còn kiểm tra nghiệp vụ là phức tạp nhất và phụ thuộc vào ngữ cảnh. Cả ba cấp độ phải được áp dụng theo trình tự: đầu tiên định dạng, sau đó ngữ nghĩa, rồi đến logic nghiệp vụ. Bỏ qua bất kỳ cấp độ nào có thể dẫn đến hoạt động sai của hệ thống hoặc lỗ hổng bảo mật.

Kiểm tra định dạng

Xác minh loại dữ liệu, kích thước, định dạng và ký tự được phép. Được triển khai qua biểu thức chính quy, loại dữ liệu tích hợp của ngôn ngữ và thư viện kiểm tra. Ví dụ: kiểm tra UUID (định dạng 8-4-4-4-12 chữ số thập lục phân), kiểm tra số điện thoại (chỉ chữ số, + ở đầu, từ 7 đến 15 ký tự), kiểm tra số nguyên (giá trị trong phạm vi Integer.MIN_VALUE — Integer.MAX_VALUE). Kiểm tra định dạng là cấp độ tối thiểu cần thiết cho bất kỳ trường nhập liệu nào.

Kiểm tra ngữ nghĩa

Xác minh tính đúng đắn về mặt logic của dữ liệu trong bối cảnh lĩnh vực. Ví dụ: ngày bắt đầu không muộn hơn ngày kết thúc, tuổi nằm trong giới hạn hợp lý của hệ thống, tọa độ nằm trong khu vực phục vụ. Kiểm tra ngữ nghĩa đòi hỏi hiểu bối cảnh nghiệp vụ và không thể thực hiện chỉ dựa trên định dạng. Ví dụ: trường "số vé" có thể vượt qua kiểm tra định dạng (số nguyên, > 0) nhưng về mặt ngữ nghĩa không thể vượt quá số ghế có sẵn.

Kiểm tra nghiệp vụ

Cấp độ phức tạp nhất — kiểm tra dữ liệu tuân thủ các quy tắc nghiệp vụ của ứng dụng. Ví dụ: người dùng không thể xóa quản trị viên duy nhất, tổng đơn hàng không vượt quá hạn mức tín dụng, sản phẩm chỉ đặt được khi còn hàng. Kiểm tra nghiệp vụ thường cần truy vấn cơ sở dữ liệu hoặc dịch vụ bên ngoài và được thực hiện sau kiểm tra định dạng và ngữ nghĩa. Lỗi kiểm tra nghiệp vụ là nguyên nhân thường gặp nhất khiến người dùng không hài lòng.

Kiểm tra phía máy khách và máy chủ

Kiểm tra phía máy khách (trong trình duyệt hoặc ứng dụng di động) cần thiết cho sự thuận tiện của người dùng: phản hồi tức thì mà không cần gửi dữ liệu lên máy chủ. Tuy nhiên, kiểm tra phía máy chủ mới là cách duy nhất đáng tin cậy, vì mã phía máy khách luôn có thể bị vượt qua. Hãy gửi yêu cầu qua công cụ dành cho nhà phát triển, Postman hoặc proxy (Burp Suite) — và kiểm tra phía máy khách không còn tồn tại. Theo PortSwigger Research (2025), hơn 90% ứng dụng web được kiểm tra chỉ dựa vào kiểm tra phía máy khách cho ít nhất một trường.

Quy tắc: máy khách cho UX, máy chủ cho bảo mật

Kiểm tra phía máy khách có thể vô hiệu hóa nút gửi, làm nổi bật lỗi và hiển thị gợi ý. Kiểm tra phía máy chủ là kiểm tra bắt buộc đối với mọi tham số, kể cả khi máy khách đã kiểm tra rồi. Nhân đôi kiểm tra ở cả hai cấp độ là thực hành chuẩn. Máy chủ phải kiểm tra dữ liệu như thể máy khách không tồn tại. Điều này đảm bảo bảo vệ khỏi yêu cầu bị sửa đổi, tấn công tự động và máy khách độc hại.

Triển khai kiểm tra phía máy khách

Trên web — thuộc tính HTML5 (required, pattern, min/max, type="email") và JavaScript. Trong ứng dụng di động — trình xác thực trường văn bản gốc (InputFilter trên Android, textField(:shouldChangeCharactersIn:) trên iOS). React Hook Form và Formik cho React, Vuelidate cho Vue, Angular Reactive Forms — các thư viện phổ biến để kiểm tra phía máy khách. Tất cả đều hỗ trợ quy tắc tùy chỉnh và kiểm tra bất đồng bộ (kiểm tra tính duy nhất của tên đăng nhập trên máy chủ).

// Ví dụ về kiểm tra phía máy chủ với Express và 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 — dữ liệu đã được kiểm tra và an toàn
    const user = await User.create(value);
    res.status(201).json(user);
});

Kiểm tra trong ứng dụng di động

Ứng dụng di động đặt ra những yêu cầu đặc biệt đối với việc kiểm tra dữ liệu. Màn hình nhỏ hơn — lỗi phải ngắn gọn, bàn phím theo ngữ cảnh (số để nhập số), và kiểm tra phải bất đồng bộ để không chặn giao diện. Các nền tảng gốc cung cấp cơ chế kiểm tra tích hợp nên được dùng mặc định. Material Design Guidelines cho Android và Human Interface Guidelines cho iOS chứa các khuyến nghị chi tiết về cách hiển thị lỗi kiểm tra.

Kiểm tra trên Android (Jetpack Compose)

Jetpack Compose cung cấp cách tiếp cận khai báo để kiểm tra thông qua quản lý trạng thái. Mỗi trường nhập liệu được gắn với một trạng thái (MutableState), và lỗi được tính dựa trên giá trị hiện tại. Thư viện Compose Validator đơn giản hóa việc tạo quy tắc: required, email, min/max length, pattern. Kiểm tra kích hoạt khi văn bản thay đổi (onValueChange) hoặc khi cố gắng gửi biểu mẫu. Nên hiển thị lỗi chỉ sau lần gửi đầu tiên hoặc sau khi người dùng nhập xong (debounce 300-500ms).

Kiểm tra trên iOS (SwiftUI)

SwiftUI không có cơ chế kiểm tra biểu mẫu tích hợp, nhưng dễ dàng triển khai qua Combine và property wrappers. Dùng @State cho giá trị trường và thuộc tính tính toán cho lỗi. Framework ValidatedPropertyKit cung cấp các decorator có sẵn: @Validated().email(), @Validated().range(18...120). Khuyến nghị iOS — dùng loại bàn phím (UIKeyboardType.emailAddress, .numberPad) và tính năng tự động viết hoa để giảm số lỗi ở cấp độ nhập liệu.

Kiểm tra trên Flutter

Flutter cung cấp lớp Form và TextFormField với kiểm tra tích hợp qua callback validator. Mỗi trường trả về lỗi dưới dạng chuỗi hoặc null nếu dữ liệu hợp lệ. FormState.validate() chạy kiểm tra tất cả các trường của biểu mẫu. Gói reactive_forms cho các trường hợp phức tạp: validator tùy chỉnh, kiểm tra bất đồng bộ, quy tắc động. Flutter Web và phiên bản di động dùng chung API, giúp việc bảo trì đơn giản hơn.

// Ví dụ về kiểm tra biểu mẫu trong 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()) {
                        // Xử lý dữ liệu hợp lệ
                    }
                },
                child: Text('Gửi'),
            ),
        ],
    ),
)

Kỹ thuật và công cụ kiểm tra

Các framework hiện đại cung cấp trình xác thực tích hợp đáp ứng 80% nhu cầu. 20% còn lại đòi hỏi quy tắc tùy chỉnh, biểu thức chính quy hoặc kết hợp các quy tắc hiện có. Nguyên tắc chính là kiểm tra phải mang tính khai báo để dễ đọc, dễ kiểm thử và dễ bảo trì. Tránh logic kiểm tra rải rác trong các controller và màn hình — hãy đưa nó vào các lớp hoặc schema riêng.

Phương pháp White-list vs Black-list

White-list (danh sách trắng) — bạn xác định dữ liệu nào được phép; mọi thứ khác bị từ chối. Black-list (danh sách đen) — bạn xác định dữ liệu nào bị cấm; mọi thứ khác được chấp nhận. Danh sách trắng luôn đáng tin cậy hơn: bạn biết chính xác dữ liệu nào sẽ được chấp nhận. Danh sách đen đòi hỏi phải lường trước mọi cuộc tấn công có thể xảy ra, điều đó là không thể. Ví dụ: khi kiểm tra tuổi, hãy dùng danh sách trắng (chỉ số từ 18 đến 120) thay vì danh sách đen (cấm "0", "-1", "999999").

Biểu thức chính quy — sức mạnh và nguy hiểm

Biểu thức chính quy là công cụ hiệu quả cho kiểm tra định dạng, nhưng chúng có thể là nguồn gây tấn công ReDoS (Regular Expression Denial of Service). Một số mẫu (ví dụ, (a+)+b) gây ra quay lui thảm khốc trên các chuỗi dài, làm CPU máy chủ quá tải hoàn toàn. Hãy dùng thư viện regex đã được kiểm chứng và giới hạn độ dài chuỗi trước khi áp dụng biểu thức chính quy. Với các trường hợp phức tạp (email, URL), hãy dùng trình phân tích cú pháp tích hợp của ngôn ngữ thay vì regex tự chế.

Các lỗi điển hình khi kiểm tra

Ngay cả lập trình viên giàu kinh nghiệm cũng mắc lỗi khi triển khai kiểm tra. Phổ biến nhất: chỉ kiểm tra ở máy khách, quy tắc quá nghiêm ngặt (mật khẩu "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters"), thông báo lỗi không có thông tin ("Error: invalid input") và bỏ qua các trường hợp biên (khoảng trắng ở đầu/cuối, ký tự Unicode, chuỗi rỗng). Mỗi lỗi này đều làm xấu trải nghiệm người dùng và có thể làm giảm tỷ lệ chuyển đổi biểu mẫu.

• Chỉ kiểm tra phía máy khách — lỗi nguy hiểm nhất: mọi yêu cầu đều có thể làm giả qua Postman hoặc cURL
• Quy tắc quá nghiêm ngặt — khiến người dùng bỏ đi: OWASP khuyến nghị yêu cầu tối thiểu khi đăng ký
• Bỏ qua Unicode — kiểm tra độ dài chuỗi theo byte (không phải ký tự) làm hỏng tiếng Nga, tiếng Trung, emoji
• Lỗi không có thông tin — "Invalid format" thay vì "Email must contain @ symbol after local part"
• Kiểm tra trường rỗng — if (value) không phân biệt chuỗi rỗng với số không, false hay "0"

Thực hành tốt nhất là hệ thống kiểm tra tập trung được bao phủ bởi kiểm thử đơn vị. Mỗi quy tắc nên được kiểm thử riêng: giá trị biên, dữ liệu hợp lệ, các cuộc tấn công điển hình (nỗ lực SQLi, payload XSS, chuỗi rất dài). Kiểm thử hồi quy đối với kiểm tra ngăn việc làm suy yếu quy tắc một cách vô tình khi tái cấu trúc mã. Dùng kiểm thử dựa trên thuộc tính (QuickCheck, fast-check) để sinh dữ liệu ngẫu nhiên và xác minh rằng kiểm tra không thất bại với ngoại lệ.