Trong nhiều dự án web/app, validation thường được hiểu đơn giản là “bắt lỗi form trước khi submit”. Ví dụ: email phải đúng định dạng, mật khẩu không được quá ngắn, số điện thoại chỉ gồm chữ số. Việc kiểm tra ở giao diện là cần thiết vì giúp người dùng nhận phản hồi nhanh hơn, nhưng nếu chỉ dừng ở frontend thì ứng dụng rất dễ gặp lỗi dữ liệu, lỗi bảo mật hoặc các tình huống khó kiểm soát về sau. Một nguyên tắc thực tế nên nhớ: frontend giúp trải nghiệm tốt hơn, backend mới là nơi quyết định dữ liệu có hợp lệ hay không. Vì sao không nên chỉ validation ở frontend? Người dùng không bắt buộc phải đi qua giao diện của bạn. Họ có thể gửi request trực tiếp bằng công cụ như Postman, curl hoặc một script tự viết. Ngoài ra, JavaScript phía trình duyệt có thể bị tắt, bị sửa hoặc bị bỏ qua hoàn toàn. Nếu backend tin tưởng tuyệt đối dữ liệu gửi lên, hệ thống có thể nhận những giá trị sai định dạng, thiếu trường bắt buộc hoặc vượt quá giới hạn nghiệp vụ. Ví dụ, một form đăng ký tài khoản có các rule sau: - Email bắt buộc và phải đúng định dạng - Mật khẩu tối thiểu 8 ký tự - Tuổi phải từ 13 trở lên - Username không được trùng Frontend có thể kiểm tra email, độ dài mật khẩu và tuổi để hiển thị lỗi ngay. Nhưng backend vẫn phải kiểm tra lại toàn bộ, đặc biệt là username có trùng hay không, vì đây là dữ liệu phụ thuộc database. Một cách tổ chức validation dễ bảo trì 1. Tách validation theo lớp Nên chia validation thành ít nhất hai nhóm: - Validation định dạng: kiểu dữ liệu, độ dài, định dạng email, số nguyên, ngày tháng - Validation nghiệp vụ: quyền truy cập, trạng thái đơn hàng, username đã tồn tại, mã giảm giá còn hiệu lực Validation định dạng thường có thể dùng chung giữa frontend và backend nếu dự án có điều kiện tổ chức tốt. Validation nghiệp vụ nên đặt chắc chắn ở backend. 2. Trả lỗi rõ ràng cho từng field Thay vì trả một thông báo chung chung như “Dữ liệu không hợp lệ”, backend nên trả về danh sách lỗi theo từng trường. Ví dụ: - email: “Email không đúng định dạng” - password: “Mật khẩu phải có ít nhất 8 ký tự” - age: “Bạn cần đủ 13 tuổi để đăng ký” Cách này giúp frontend hiển thị lỗi đúng vị trí, người dùng sửa nhanh hơn và lập trình viên cũng dễ debug hơn. 3. Không lộ chi tiết nhạy cảm Thông báo lỗi cần đủ rõ để người dùng hiểu, nhưng không nên tiết lộ thông tin có thể bị lợi dụng. Ví dụ, với form đăng nhập, thay vì nói “Email không tồn tại” hoặc “Mật khẩu sai”, nhiều hệ thống chọn thông báo chung như “Thông tin đăng nhập không chính xác”. Điều này giúp giảm khả năng dò tài khoản. 4. Chuẩn hóa rule để tránh mỗi nơi một kiểu Một lỗi phổ biến là frontend yêu cầu mật khẩu tối thiểu 8 ký tự, còn backend lại yêu cầu 10 ký tự. Người dùng nhập đúng theo giao diện nhưng submit vẫn thất bại. Để tránh tình trạng này, nhóm phát triển nên lưu rule ở nơi rõ ràng, có tài liệu nội bộ hoặc dùng schema chung nếu phù hợp với stack kỹ thuật. 5. Kiểm tra cả trường hợp biên Khi viết validation, đừng chỉ thử dữ liệu “đẹp”. Hãy kiểm tra thêm: - Chuỗi rỗng hoặc toàn dấu cách - Dữ liệu quá dài - Số âm khi chỉ cho phép số dương - Ngày không hợp lệ - File sai định dạng hoặc vượt dung lượng - Ký tự đặc biệt trong tên, địa chỉ, ghi chú Nhiều lỗi thực tế xuất hiện từ các trường hợp rất nhỏ như người dùng nhập khoảng trắng ở đầu/cuối email hoặc gửi một chuỗi dài bất thường vào ô ghi chú. Lời khuyên áp dụng ngay Nếu bạn đang phát triển một form mới, hãy bắt đầu bằng cách viết danh sách rule trước khi code giao diện. Sau đó triển khai validation ở frontend để tăng trải nghiệm, và triển khai lại ở backend để bảo vệ dữ liệu. Với các form quan trọng như đăng ký, thanh toán, cập nhật thông tin cá nhân hay tạo đơn hàng, nên có test cho các trường hợp sai phổ biến. Validation tốt không chỉ là bắt lỗi người dùng. Nó là một phần của thiết kế hệ thống: giúp dữ liệu sạch hơn, giảm lỗi vận hành, tăng bảo mật và giúp ứng dụng dễ bảo trì khi nghiệp vụ ngày càng phức tạp.