Họ đang đo gì
Bạn có coi client là môi trường thù địch không — nguyên tắc nền của mọi bảo mật web.
Trả lời ngắn~30 giây
Ở client để có TRẢI NGHIỆM tốt: báo lỗi ngay, không bắt người dùng chờ một vòng mạng để biết mình gõ sai email. Ở server vì BẢO MẬT: mọi thứ ở client đều sửa được — DevTools, curl, hay một client tự viết — nên kiểm tra ở đó không phải một lớp bảo vệ, nó chỉ là một gợi ý. Quy tắc: client kiểm tra để giúp người dùng trung thực, server kiểm tra để chặn người không trung thực.
Giải thích sâu
Cách làm cho việc này bền vững là dùng CHUNG một định nghĩa schema cho cả hai phía — Zod là ví dụ điển hình: một schema chạy được ở form và ở server action, nên hai bên không thể lệch nhau. Khi định nghĩa bị nhân đôi, kiểu gì cũng có ngày ai đó nới lỏng ở một bên và quên bên kia, và lỗ hổng nằm chính xác ở khoảng chênh đó.
Điều thường bị bỏ sót là kiểm tra ở server phải là danh sách CHO PHÉP chứ không phải danh sách chặn, và phải áp cho cả những trường mà giao diện không hiển thị. Một endpoint cập nhật hồ sơ nhận nguyên object rồi ghi vào database sẽ vui vẻ nhận thêm trường role: "admin" mà không form nào từng gửi nó — mass assignment, và đó là lý do bạn liệt kê trường được phép thay vì loại trường bị cấm.
Câu hỏi tiếp theo họ sẽ hỏi
?Làm sạch dữ liệu (sanitize) và kiểm tra (validate) khác nhau ra sao?
Kiểm tra là từ chối dữ liệu không hợp lệ; làm sạch là biến đổi nó cho an toàn. Nguyên tắc thực dụng: kiểm tra ở ĐẦU VÀO, làm sạch ở ĐẦU RA và theo ngữ cảnh — cùng một chuỗi cần escape khác nhau khi vào HTML, vào thuộc tính, hay vào một câu lệnh shell.
Trả lời thế này là mất điểm
- Chỉ kiểm tra ở client vì “API của chúng ta là nội bộ”. Nội bộ hôm nay là công khai sau lần refactor sau.