Biểu mẫu website: thiết kế, kiểm tra dữ liệu và chống spam

Biểu mẫu là nơi khách để lại thông tin liên hệ, nên mỗi ô thừa, mỗi thông báo lỗi khó hiểu và mỗi tin rác lọt qua đều có giá. Phần lớn lỗi nằm ở chi tiết nhỏ: thiếu nhãn, chỉ kiểm tra ở trình duyệt, gắn CAPTCHA mà không xác minh ở máy chủ.

Bài này trình bày cách thiết kế biểu mẫu liên hệ, kiểm tra dữ liệu ở trình duyệt và máy chủ, các lớp chống spam và cách nối vào CRM. Mọi nguồn được đối chiếu đến ngày 23/10/2026.

Nguồn gồm MDN, web.dev, OWASP, W3C, Cloudflare Turnstile, Google reCAPTCHA (nay thuộc Google Cloud Fraud Defense), NN/g và Baymard.

Điểm chính

• Hỏi ít hơn: theo Baymard (26/6/2024), quy trình thanh toán trung bình có 11,3 ô trong khi phần lớn website chỉ cần 8 ô cho thanh toán. Số này đo trên thương mại điện tử, chưa phải biểu mẫu liên hệ.
• Dùng nhãn thật, đúng kiểu nhập và autocomplete. Mẫu chỉ nhận chữ Latin cơ bản sẽ từ chối tên có dấu tiếng Việt.
• Kiểm tra ở trình duyệt chỉ để tiện cho khách. MDN và OWASP đều nói máy chủ phải kiểm tra lại.
• Chống spam theo lớp từ nhẹ đến nặng: ô bẫy (honeypot), giới hạn tần suất, kiểm tra không tương tác. Bản dự thảo W3C (2021) khuyên: nếu honeypot đủ thì dùng nó cho đến khi có bằng chứng bị tấn công.
• Token của Turnstile và reCAPTCHA chỉ có tác dụng khi máy chủ xác minh. Mỗi token dùng 1 lần, sống 300 giây ở Turnstile và 2 phút ở reCAPTCHA.
• Đo bằng tỷ lệ gửi được chấp nhận, tỷ lệ gắn cờ spam và số khách thật bị chặn nhầm, không chỉ bằng form_submit của GA4.

Biểu mẫu nên hỏi bao nhiêu ô

Chỉ hỏi điều bạn dùng ngay. web.dev (viết cho biểu mẫu thanh toán và địa chỉ; trang cập nhật 22/10/2026) khuyên không xin dữ liệu không cần, vì bớt ô vừa giảm độ phức tạp vừa giảm chi phí và trách nhiệm lưu trữ. MDN cũng khuyên chỉ bắt buộc những gì thật cần.

Baymard (bài ngày 26/6/2024) ghi quy trình thanh toán năm 2024 trung bình có 5,1 bước và 11,3 ô. Baymard cho rằng phần lớn website chỉ cần 8 ô cho thanh toán, và số ô ảnh hưởng trải nghiệm nhiều hơn số bước.

Giới hạn: đó là dữ liệu thanh toán của cửa hàng trực tuyến.

web.dev khuyên dùng 1 ô tên duy nhất. Khung tham khảo của Click Star, không lấy từ nguồn ngoài: biểu mẫu liên hệ bắt đầu với 3 ô bắt buộc (họ tên, số điện thoại hoặc email, nhu cầu), mọi ô khác để tùy chọn.

Nhãn, kiểu nhập và autocomplete

Mỗi ô cần 1 nhãn nhìn thấy. web.dev cảnh báo không dùng placeholder thay nhãn vì chữ biến mất khi bắt đầu gõ. NN/g (đăng 11/5/2014) nêu 7 lý do, như gánh nặng trí nhớ và không kiểm lại được câu trả lời.

WCAG 2.2 tiêu chí 3.3.2 (mức A) yêu cầu nhãn hoặc hướng dẫn cho ô nhập.

Kiểu nhập (type) quyết định bàn phím trên điện thoại. web.dev khuyên dùng type="email" và type="tel", không dùng type="number" cho số điện thoại vì nó thêm nút tăng giảm vô nghĩa. MDN lưu ý trình duyệt không ép định dạng số điện thoại, vì khó có một cách kiểm tra đúng cho mọi nơi.

Thuộc tính autocomplete cho trình duyệt biết ô nhận loại dữ liệu nào; MDN liệt kê các giá trị như name, email, tel và organization. WCAG 1.3.5 (mức AA) yêu cầu mục đích của ô thu thập thông tin người dùng xác định được bằng chương trình. web.dev thêm: giữ name và id ổn định.

Với tên người, web.dev khuyên đừng bắt chữ Latin: nên dùng mẫu nhận mọi chữ cái Unicode (ví dụ \p{L}). Mẫu chỉ nhận chữ Latin cơ bản sẽ từ chối "Nguyễn" hay "Đặng", đó là hệ quả trực tiếp của cách mẫu hoạt động.

Thông báo lỗi: đúng chỗ, đúng lúc

NN/g (đăng 3/2/2019, cập nhật 12/12/2024) đưa ra 10 nguyên tắc báo lỗi. Điều cốt lõi: báo ngay khi khách xong ô đó, đặt thông báo cạnh ô lỗi, không báo trước khi khách gõ xong, không dùng tóm tắt đầu trang làm dấu hiệu duy nhất và không dùng tooltip để báo lỗi.

WCAG 3.3.1 (mức A) yêu cầu lỗi được nêu bằng chữ và chỉ rõ ô sai. web.dev khuyên đừng khóa nút gửi chỉ vì dữ liệu chưa hợp lệ, vì khách dễ tưởng nút hỏng. Ngược lại, web.dev nói nên cân nhắc vô hiệu hóa nút ngay sau khi bấm gửi để tránh gửi trùng.

Kiểm tra phía máy chủ là bắt buộc

MDN viết rõ: kiểm tra ở trình duyệt không thể coi là biện pháp bảo mật đầy đủ, vì người xấu có thể sửa yêu cầu mạng; một trang MDN khác nói họ còn có thể bỏ qua giao diện để gửi thẳng đến máy chủ. OWASP cùng kết luận: dùng kiểm tra ở trình duyệt để phản hồi nhanh, nhưng máy chủ vẫn phải kiểm tra lại.

Theo OWASP, cần kiểm tra cả cú pháp (đúng kiểu, định dạng) lẫn ý nghĩa (ví dụ ngày kết thúc phải sau ngày bắt đầu), với quy tắc riêng cho từng trường.

OWASP khuyên định nghĩa điều được chấp nhận thay vì cố nhận diện mọi chuỗi độc hại; chặn dấu nháy đơn chẳng hạn sẽ từ chối tên hợp lệ mà không làm truy vấn an toàn hơn. Hãy đặt giới hạn kích thước yêu cầu trước khi đọc nội dung.

Về email, OWASP nói kiểm tra định dạng không chứng minh người gửi có quyền với hộp thư; OWASP dẫn sang hướng dẫn xác minh quyền sở hữu email. Suy luận của Click Star: muốn chắc địa chỉ dùng được, hãy gửi thư xác nhận.

Chống spam: 4 lớp từ nhẹ đến nặng

OWASP định nghĩa "spamming" (OAT-017) là thêm thông tin độc hại hoặc đáng ngờ vào nội dung hay tin nhắn, trong đó có form spam. Trang này tách riêng việc lạm dụng hàm gửi email hoặc SMS từ biểu mẫu bị lỗi: OWASP coi đó là lỗi cài đặt, không phải đe dọa tự động.

Khung tham khảo của Click Star, không phải lời OWASP: trước khi tìm công cụ chặn bot, hãy chắc biểu mẫu không cho gửi đến người nhận do người lạ chọn. Thứ tự 4 lớp dưới đây cũng là khung của Click Star (dựa trên W3C và tài liệu nhà cung cấp).

Lớp 1, ô bẫy (honeypot). Bản dự thảo "Inaccessibility of CAPTCHA" của W3C (16/12/2021) mô tả honeypot là ô dựng để thu hút robot rồi ẩn khỏi người dùng, dễ làm cả bằng HTML viết tay. Bản này kết luận: nếu honeypot đủ thì dùng nó cho đến khi có bằng chứng tấn công.

Suy luận của Click Star: đặt tên ô không giống ô thật, ẩn khỏi người đọc màn hình và thử với trình quản lý mật khẩu, vì trình duyệt có thể điền nhầm vào ô ẩn.

Lớp 2, giới hạn tần suất. Tài liệu Vercel (cập nhật 28/8/2026) nói WAF Rate Limiting có trên mọi gói, đếm yêu cầu cùng nguồn trong 1 khoảng thời gian, mặc định trả lỗi 429, và có hành động "Log" để quan sát trước khi chặn.

Lớp 3, kiểm tra không tương tác. Cloudflare Turnstile (tài liệu cập nhật 14/8/2026) chạy thử thách nhỏ trong nền, có 3 chế độ: Managed, Non-interactive và Invisible. Gói Free cho tối đa 20 widget, thử thách không giới hạn.

Theo trang Widget (16/4/2026), Managed (Cloudflare khuyến nghị) có thể hiện ô tick tùy mức rủi ro; chỉ Non-interactive và Invisible không bao giờ cần khách thao tác. Chế độ Invisible đòi hỏi chính sách quyền riêng tư của bạn tham chiếu Turnstile Privacy Addendum.

Tài liệu Turnstile (22/10/2026) nhấn mạnh: widget chưa đủ, bắt buộc gọi API Siteverify ở máy chủ vì token có thể bị giả. Token hợp lệ 300 giây, dùng 1 lần; lỗi timeout-or-duplicate báo token hết hạn hoặc đã dùng.

reCAPTCHA đã đổi chỗ: các trang cũ trên Google for Developers ghi "deprecated" và dẫn sang Google Cloud Fraud Defense (đọc 23/10/2026). Trang chuyển đổi (cập nhật 13/10/2026) nói khóa v2 và v3 hiện có vẫn chạy không cần sửa mã khi được chuyển sang dự án Google Cloud.

Luồng mới: máy chủ gọi assessments.create và nhận điểm rủi ro 0,0 đến 1,0; token dùng 1 lần, hết hạn sau 2 phút, và action trả về phải khớp expectedAction.

Theo trang thanh toán của Fraud Defense (13/10/2026), Essentials miễn phí đến 10.000 lượt đánh giá mỗi tháng dương lịch (tính theo tổ chức, áp cho dự án chưa bật thanh toán); vượt mức này, yêu cầu bị trả lỗi 429. Premium áp khi bật thanh toán: 10.001 đến 100.000 lượt tính $8 cố định mỗi tháng (trang không nêu loại tiền).

Lớp 4, thử thách nhìn thấy. W3C ghi rằng CAPTCHA tương tác loại trừ nhiều người khuyết tật, ngày càng kém an toàn, và khuyên giảm số lần khách bị hỏi.

Từ biểu mẫu vào CRM: không để mất khách thật

Các điểm sau là khung tham khảo của Click Star, trừ chỗ ghi nguồn. Thứ nhất, lưu bản ghi thô của mọi lượt gửi đúng cú pháp trước khi gọi dịch vụ ngoài, để lỗi của bên thứ ba không làm mất lead.

Thứ hai, gắn cờ thay vì xóa: lượt nghi spam vào hàng chờ duyệt và có người xem mẫu mỗi tuần.

Thứ ba, khử trùng lặp theo số điện thoại hoặc email khi vào CRM. Thứ tư, mã ví dụ của Cloudflare trả thất bại khi không gọi được Siteverify; đóng hay mở khi dịch vụ ngoài lỗi là quyết định kinh doanh, nên chọn trước.

Cách đo biểu mẫu

Trang Enhanced measurement events của Google Analytics mô tả form_start, ghi lần đầu khách tương tác với biểu mẫu trong phiên, và form_submit, ghi khi khách gửi.

Trang không nói form_submit có nghĩa máy chủ đã chấp nhận. Suy luận của Click Star: đó là sự kiện trình duyệt, nên cần đối chiếu với số bản ghi thật ở máy chủ. Bộ chỉ số tham khảo của Click Star, không phải chuẩn ngành (Click Star không tìm thấy ngưỡng chuẩn có nguồn mở được, nên hãy so với chính website của bạn theo tuần):

• Tỷ lệ bắt đầu: form_start chia lượt xem trang có biểu mẫu.
• Tỷ lệ gửi được chấp nhận: lượt máy chủ chấp nhận chia lượt bấm gửi.
• Tỷ lệ gắn cờ spam: lượt bị gắn cờ chia tổng lượt nhận.
• Khách thật bị chặn nhầm: số lượt thật trong mẫu kiểm tay hàng tuần.

Ý nghĩa với website doanh nghiệp Việt Nam

Suy luận của Click Star từ các nguồn trên, 3 điểm áp dụng được ngay: họ tên có dấu phải nhập được, số điện thoại cần chuẩn hóa ở máy chủ, và dịch vụ chống bot của bên thứ ba nên được nêu trong chính sách quyền riêng tư (Turnstile Invisible bắt buộc điều này).

Biểu mẫu thu thập dữ liệu cá nhân, nên cần xem quy định liên quan. Click Star đã có bài riêng về luật bảo vệ dữ liệu cá nhân và banner cookie; bài này không nêu điều khoản cụ thể, hãy đối chiếu văn bản gốc hoặc hỏi luật sư.

Đánh giá của Click Star. Thứ tự hợp lý là bớt ô và sửa nhãn trước, kiểm tra máy chủ sau, rồi mới chống spam theo lớp. Spam thường là triệu chứng của biểu mẫu thiếu kiểm tra, không chỉ là vấn đề công cụ.

Click Star làm dịch vụ thiết kế website và tích hợp CRM, nên có lợi ích liên quan đến chủ đề.

Lộ trình 14 ngày (khung tham khảo của Click Star)

• Ngày 1 đến 2: bỏ ô không ai dùng, thêm nhãn, type và autocomplete đúng.
• Ngày 3 đến 4: kiểm tra lại mọi trường ở máy chủ, đặt giới hạn độ dài và kích thước yêu cầu.
• Ngày 5 đến 7: thêm honeypot và giới hạn tần suất, để chế độ ghi nhật ký trước khi chặn.
• Ngày 8 đến 10: nếu spam vẫn lọt, bật Turnstile hoặc reCAPTCHA và xác minh token ở máy chủ.
• Ngày 11 đến 14: bật đo 4 chỉ số, xem mẫu lượt bị gắn cờ và chỉnh ngưỡng.

Những sai lầm thường gặp

1. Chỉ kiểm tra bằng HTML và JavaScript, máy chủ nhận mọi thứ.
2. Gắn widget CAPTCHA nhưng không gọi xác minh token ở máy chủ.
3. Dùng placeholder thay nhãn, hoặc type="number" cho số điện thoại.
4. Dùng mẫu chỉ nhận chữ Latin cơ bản cho họ tên, làm khách có dấu bị từ chối.
5. Xóa im lặng mọi lượt bị cho là spam mà không xem mẫu, nên mất khách thật.
6. Coi form_submit của GA4 là số lead thật, không đối chiếu bản ghi ở máy chủ.
7. Bật thử thách nhìn thấy cho mọi khách từ đầu, dù chưa có bằng chứng bị tấn công.

Điều chưa biết

Chưa có số đo cho Việt Nam về tỷ lệ bỏ biểu mẫu, spam hay tác động của CAPTCHA lên chuyển đổi. Số của Baymard thuộc thương mại điện tử, chưa kiểm cho biểu mẫu liên hệ ngắn.

Không có nguồn chính về hiệu quả của honeypot với bot hiện nay hay về xung đột với trình quản lý mật khẩu. Nguồn đọc được là bản dự thảo W3C 2021, chính nó cảnh báo hiệu quả của biện pháp chống bot có thể đổi theo thời gian.

Tài liệu reCAPTCHA đang chuyển nền tảng nên tên gói, giá và tính năng có thể đổi. Trang Turnstile ghi WCAG 2.2 AA ở trang tổng quan và AAA ở bảng gói, Click Star chưa kiểm độc lập mức nào đúng.