กลับไปยังบล็อก
พื้นฐาน เผยแพร่ 19.08.2026 ใช้เวลาอ่าน 1 นาที

อะไรปกป้องแบบฟอร์มได้จริง: CAPTCHA ช่องดักบอต กับดักเวลา และ CSRF

แบบฟอร์มติดต่อส่วนใหญ่พึ่งเทคนิคเดียวในการต้านสแปม และหลายเทคนิคหยุดได้เฉพาะบอตที่ง่ายที่สุด แต่ละชั้นหยุดอะไร มีต้นทุนอะไร และควรใช้ร่วมกันอย่างไร

สแปมผ่านแบบฟอร์มติดต่อแทบไม่เคยมาจากคนที่พิมพ์ด้วยมือ ส่วนใหญ่เป็นซอฟต์แวร์ที่หาแบบฟอร์ม กรอกทุกช่อง แล้วส่งผลลัพธ์ซ้ำหลายพันครั้ง มีวิธีป้องกันหลายแบบที่ทำงานในจุดต่างกันมาก การรู้ว่าแต่ละแบบทำอะไรได้จริงช่วยหลีกเลี่ยงข้อผิดพลาดสองอย่าง: แบบฟอร์มที่ไม่มีการป้องกันจริง และแบบฟอร์มที่ป้องกันแน่นหนาจนผู้ใช้จริงยอมแพ้

เปรียบเทียบชั้นการป้องกัน
ชั้นการป้องกันและสิ่งที่หยุดได้
  • ช่องดักบอต: บอตง่าย ๆ ที่กรอกทุกช่อง
  • กับดักเวลา: สคริปต์ที่ส่งทันทีหลังโหลด
  • CAPTCHA: ระบบอัตโนมัติทั่วไปส่วนใหญ่
  • โทเค็น CSRF: คำขอที่ส่งตรงไปยังเอนด์พอยต์
  • การจำกัดอัตรา: การส่งถล่มจากแหล่งเดียว
  • การพิสูจน์การทำงาน: การส่งจำนวนมากที่มีต้นทุนต่ำ โดยไม่ติดตามหรือใช้ปริศนา
  • การตรวจสอบฝั่งเซิร์ฟเวอร์: ทุกอย่างที่ข้ามเบราว์เซอร์
สิ่งที่หยุดไม่ได้หรือต้นทุนที่ต้องจ่าย
  • บอตที่เจาะจงเว็บไซต์จะข้ามช่องนี้ หากซ่อนไม่ดี โปรแกรมอ่านหน้าจอจะอ่านให้ฟัง
  • บอตที่รอเวลา และหากไม่มีลายเซ็นฝั่งเซิร์ฟเวอร์ก็ปลอมได้ง่าย
  • เป็นอุปสรรคสำหรับทุกคน มีข้อจำกัดด้านการเข้าถึง มักพึ่งบุคคลที่สาม และมีบริการรับแก้ CAPTCHA
  • บอตที่โหลดหน้าก่อนก็ได้รับโทเค็นที่ถูกต้องเช่นกัน
  • สแปมที่กระจายมาจากที่อยู่ IP จำนวนมาก
  • ผู้ส่งที่มุ่งมั่นและมีกำลังประมวลผล โดยต้องใช้ JavaScript
  • เพียงลำพังไม่ได้ป้องกันอะไร แต่หากไม่มี การป้องกันชั้นอื่นทั้งหมดก็เป็นเพียงของตกแต่ง
ไม่มีชั้นใดครอบคลุมทุกอย่าง ชั้นที่ต้นทุนต่ำและมองไม่เห็นกรองปัญหาส่วนใหญ่ ส่วนชั้นที่หนักกว่าใช้รับมือสแปมเจาะจงที่ไม่ยอมเลิก

ช่องดักบอตและกับดักเวลา: ตัวกรองที่มองไม่เห็น

ช่องดักบอตคือช่องเสริมที่คนมองไม่เห็น เช่น ช่องชื่อ “website” ที่ซ่อนด้วย CSS บอตง่าย ๆ จะกรอกทุกช่อง ดังนั้นช่องดักบอตที่มีข้อมูลจึงบ่งชี้การทำงานอัตโนมัติ และเซิร์ฟเวอร์สามารถทิ้งข้อความเงียบ ๆ ได้ บอตที่เขียนมาเพื่อเว็บไซต์นี้หรือบอตที่เรนเดอร์หน้าเหมือนเบราว์เซอร์จะข้ามช่องนี้ ต้องซ่อนให้ถูกวิธี: ช่องที่เพียงย้ายออกนอกหน้าจออาจถูกโปรแกรมอ่านหน้าจออ่าน เข้าถึงด้วยปุ่ม Tab หรือถูกกรอกอัตโนมัติได้ ใช้ aria-hidden, tabindex -1 และ autocomplete off พร้อมป้ายกำกับที่เป็นกลางเพื่อบอกผู้ที่เข้าถึงช่องนั้นให้เว้นว่างไว้

กับดักเวลาบันทึกเวลาที่ส่งแบบฟอร์มให้ผู้ใช้และปฏิเสธข้อมูลที่ส่งกลับเร็วเกินจริง คนต้องใช้เวลาสองสามวินาทีเพื่ออ่านและพิมพ์ แต่หลายสคริปต์ส่งภายในเสี้ยววินาที ต้องตรวจเวลาที่เซิร์ฟเวอร์และป้องกันการแก้ไข เช่น ลงลายเซ็นหรือเก็บไว้ในเซสชัน เพราะบอตเขียนทับช่องเวลาที่ซ่อนธรรมดาได้ง่าย ควรกำหนดเกณฑ์ให้ต่ำ เนื่องจากการกรอกอัตโนมัติก็ทำให้คนจริงกรอกเร็วได้ บอตที่เพียงรอเวลาก็ผ่านได้: กับดักเวลาเป็นตัวกรอง ไม่ใช่กำแพง

CAPTCHA: ได้ผล แต่มีต้นทุน

CAPTCHA ขอหลักฐานว่าไม่มีบอตกำลังทำงาน ตั้งแต่ปริศนารูปภาพไปจนถึงการตรวจที่ทำงานเบื้องหลัง บริการที่พบบ่อย ได้แก่ reCAPTCHA, hCaptcha, Cloudflare Turnstile และ Friendly Captcha วิธีนี้หยุดระบบอัตโนมัติทั่วไปได้ส่วนใหญ่ จึงเป็นที่นิยม แต่ทุกปริศนาที่มองเห็นเป็นอุปสรรคที่ทำให้ผู้เยี่ยมชมบางคนยอมแพ้ และบริการส่วนใหญ่โหลดสคริปต์ของบุคคลที่สามซึ่งทำให้เกิดคำถามเรื่องความเป็นส่วนตัวและความยินยอม CAPTCHA ยังช่วยได้ก็ต่อเมื่อตั้งค่าถูกต้อง คีย์เว็บไซต์ทดสอบสาธารณะ วิดเจ็ตที่ไม่มีสคริปต์ หรือโทเค็นที่เซิร์ฟเวอร์ไม่เคยตรวจสอบ ล้วนดูเหมือนป้องกันแต่ไม่ได้ป้องกัน การตรวจสอบฟรีที่ formexposed.com ชี้ข้อผิดพลาดเหล่านี้จากภายนอก

การเข้าถึงเป็นส่วนหนึ่งของต้นทุนนี้ ปริศนารูปภาพกีดกันคนตาบอดและคนสายตาเลือนรางจำนวนมาก ทางเลือกเสียงไม่ช่วยคนที่หูหนวกและตาบอด และโจทย์ตรรกะซับซ้อนเพิ่มภาระให้ผู้มีความบกพร่องทางการรู้คิด เกณฑ์ความสำเร็จ 1.1.1 ของ WCAG 2.2 กำหนดให้มีข้อความทางเลือกที่อธิบายวัตถุประสงค์ของ CAPTCHA และรูปแบบทางเลือกสำหรับประสาทสัมผัสต่างกัน การตรวจเบื้องหลังหลีกเลี่ยงปัญหาส่วนใหญ่ได้ แต่เมื่อพบสิ่งน่าสงสัย วิธีสำรองมักกลับเป็นปริศนารูปภาพอีก จึงต้องทดสอบเส้นทางนั้นด้วยแป้นพิมพ์และโปรแกรมอ่านหน้าจอ

โทเค็น CSRF: ป้องกันการปลอมคำขอ ไม่ใช่สแปม

โทเค็น CSRF คือค่าสุ่มที่เซิร์ฟเวอร์ใส่ในแบบฟอร์มและคาดว่าจะได้รับกลับมา ออกแบบมาเพื่อต้านการปลอมคำขอข้ามเว็บไซต์ ซึ่งเว็บไซต์อื่นทำให้เบราว์เซอร์ของผู้เยี่ยมชมส่งคำขอที่เจ้าตัวไม่ได้ตั้งใจ สำหรับแบบฟอร์มติดต่อสาธารณะ มีผลข้างเคียงคือปฏิเสธบอตที่ส่งตรงไปยังที่อยู่แบบฟอร์มโดยไม่โหลดหน้า บอตใดที่ดึงหน้ามาก่อนแล้วส่งโทเค็นกลับก็ผ่านได้ เฟรมเวิร์กและปลั๊กอินแบบฟอร์มส่วนใหญ่มีโทเค็น CSRF อยู่แล้ว ควรเปิดไว้ แต่ไม่ควรนับเป็นการป้องกันสแปม

สิ่งที่ต้องเกิดขึ้นบนเซิร์ฟเวอร์

การตรวจเฉพาะในเบราว์เซอร์ไม่ได้ป้องกันอะไร
ทุกอย่างที่ทำงานเฉพาะในเบราว์เซอร์ ไม่ว่าจะเป็นการตรวจข้อมูลด้วย JavaScript สคริปต์ตรวจช่องดักบอต หรือโทเค็น CAPTCHA ที่ไม่มีใครตรวจสอบ จะถูกข้ามทันทีเมื่อมีคนส่งคำขอโดยตรง การตัดสินใจทุกครั้งว่าจะรับข้อความหรือไม่ต้องอยู่ที่เซิร์ฟเวอร์
  • ตรวจสอบทุกช่องซ้ำที่เซิร์ฟเวอร์ ทั้งช่องที่ต้องกรอก ความยาว รูปแบบอีเมล และห้ามมีการขึ้นบรรทัดใหม่ในช่องที่จะนำไปใส่ในส่วนหัวอีเมล
  • ตรวจสอบโทเค็น CAPTCHA และการพิสูจน์การทำงานทุกครั้งที่มีการส่ง โดยตรวจกับบริการผู้ออกหรือในโค้ดของตนเอง และปฏิเสธโทเค็นที่นำกลับมาใช้ซ้ำ
  • จำกัดการส่งตามที่อยู่ IP และช่วงเวลา วิธีนี้หยุดการส่งถล่มจากแหล่งเดียวได้ ส่วนสแปมที่กระจายหลายที่อยู่ต้องใช้ชั้นอื่น
  • พิจารณาการพิสูจน์การทำงาน: ก่อนส่ง เบราว์เซอร์แก้โจทย์คำนวณเล็กน้อย ผู้เยี่ยมชมไม่เห็นปริศนาและไม่มีการติดตาม แต่การส่งจำนวนมากมีต้นทุนสูงขึ้น

การใช้ร่วมกันอย่างเหมาะสม: สองหรือสามชั้น

  1. 1เริ่มจากชั้นที่มองไม่เห็น: ช่องดักบอตที่รองรับการเข้าถึงและกับดักเวลาที่ลงลายเซ็น โดยตรวจทั้งสองอย่างที่เซิร์ฟเวอร์
  2. 2เพิ่มการจำกัดอัตราต่อที่อยู่ IP เพื่อไม่ให้แหล่งเดียวส่งถล่มแบบฟอร์มได้
  3. 3หากสแปมที่เจาะจงยังผ่านได้ ให้เพิ่มการพิสูจน์การทำงานหรือ CAPTCHA โดยควรเลือกแบบที่ไม่มีปริศนาให้เห็นและมีทางเลือกที่รองรับการเข้าถึง
  4. 4เก็บโทเค็น CSRF ที่เฟรมเวิร์กให้มาไว้ โดยถือเป็นประโยชน์เสริม ไม่ใช่มาตรการต้านสแปม
  5. 5ทดสอบผลลัพธ์ในฐานะผู้เยี่ยมชม ทั้งใช้แป้นพิมพ์อย่างเดียว ใช้โปรแกรมอ่านหน้าจอ และใช้โทรศัพท์ พร้อมตรวจว่าข้อความจริงยังส่งถึง

สำหรับหลายเว็บไซต์ การใช้ช่องดักบอต กับดักเวลา และการจำกัดอัตราร่วมกันก็ขจัดสแปมทั่วไปส่วนใหญ่ได้แล้วโดยไม่มีอุปสรรคที่มองเห็น CAPTCHA เป็นตัวสำรองเมื่อยังไม่เพียงพอ บน WordPress ปลั๊กอินฟรีของ formexposed รวมช่องดักบอต การตรวจสอบเวลา และการพิสูจน์การทำงานโดยไม่ต้องใช้ Google หากต้องการดูสิ่งที่แบบฟอร์มแสดงจากภายนอก ว่ามีชั้นใดบ้างและตั้งค่า CAPTCHA อย่างมีประสิทธิภาพหรือไม่ การตรวจสอบฟรีที่ formexposed.com ใช้เพียงโดเมน ไม่ต้องมีบัญชี แต่ไม่สามารถเห็นโค้ดเซิร์ฟเวอร์ได้ ดังนั้นส่วนฝั่งเซิร์ฟเวอร์ยังเป็นหน้าที่ของผู้ดูแล