สรุปคำตอบ
การป้องกันเว็บโดนแฮกคือชุดมาตรการที่ลดโอกาสที่ผู้ไม่ได้รับอนุญาตจะเข้าถึงหรือฝังโค้ดอันตรายในเว็บ และจำกัดความเสียหายถ้าเกิดเหตุ สำหรับ WordPress ให้เริ่มจากอัปเดต Plugin และ Theme อย่างรวดเร็วและลบตัวที่ไม่ใช้ เพราะช่องโหว่ราว 91% ในปี 2025 อยู่ใน Plugin จากนั้นงดใช้ของเถื่อน ใช้รหัสผ่านยาวไม่ซ้ำร่วมกับ 2FA ตั้งสิทธิ์ wp-config.php เป็น 400 หรือ 440 และมี Backup แบบ 3-2-1 ที่ทดสอบกู้คืนได้จริง
การป้องกันเว็บโดนแฮก คือชุดมาตรการที่ลดโอกาสที่ผู้ไม่ได้รับอนุญาตจะเข้าถึง แก้ไข หรือฝังโค้ดอันตรายลงในเว็บไซต์ และจำกัดความเสียหายถ้าเกิดเหตุขึ้นจริง สำหรับ WordPress มาตรการเหล่านี้แบ่งได้เป็น 3 ชั้น คือ ปิดช่องโหว่ของซอฟต์แวร์ (Core, Plugin, Theme) ป้องกันบัญชีผู้ใช้ไม่ให้ถูกยึด และเตรียมระบบสำรองข้อมูลกับการเฝ้าระวังไว้ล่วงหน้า
เดือนตุลาคม 2026 มีช่องโหว่ร้ายแรงในตัว PHP ที่อัปเดต WordPress อย่างเดียวแก้ไม่ได้ ดูวิธีจัดการที่ ช่องโหว่ PHP ล่าสุด 21 ต.ค. 2026
บทความนี้อธิบายวิธีป้องกัน WordPress โดนแฮกในมุม “ทำไม” และ “ทำอย่างไร” ของแต่ละข้อ โดยอ้างอิงคู่มือของ WordPress.org, NIST และ CISA ถ้าต้องการรายการติ๊กถูกแบบสั้น ดูได้ที่ WordPress Security Checklist สำหรับเจ้าของเว็บไซต์ และถ้าต้องการเข้าใจก่อนว่าแฮกเกอร์ฝังอะไรไว้ในเว็บบ้าง อ่านภาพรวมที่ Malware คืออะไร มัลแวร์และไวรัสเว็บไซต์ 12 ประเภท
ทำไม WordPress ถึงถูกโจมตีบ่อย
เหตุผลแรกคือขนาดของฐานผู้ใช้ ข้อมูลของ W3Techs ณ วันที่ 2 ตุลาคม 2026 ระบุว่า WordPress ถูกใช้ในเว็บไซต์ราว 40.2% ของเว็บไซต์ทั้งหมด หรือ 58.7% ของเว็บไซต์ที่ระบุ CMS ได้ ผู้โจมตีที่เขียนโค้ดเจาะช่องโหว่ได้หนึ่งชุดจึงนำไปสแกนเว็บจำนวนมหาศาลได้โดยอัตโนมัติ คู่มือเรื่อง Brute Force Attacks ของ WordPress.org ก็ระบุว่าการสุ่มรหัสผ่านเกิดได้กับทุกเว็บแอปที่มีหน้าล็อกอิน แต่ความนิยมของ WordPress ทำให้กลายเป็นเป้าหมายที่พบบ่อย และการโจมตีมักกระจายมาจาก botnet
เหตุผลที่สองคือจำนวนช่องโหว่ใน Plugin และ Theme รายงาน State of WordPress Security in 2026 ของ Patchstack สรุปข้อมูลปี 2025 ไว้ดังนี้
- พบช่องโหว่ใหม่ 11,334 รายการ เพิ่มขึ้น 42% จากปี 2024
- 91% อยู่ใน Plugin และ 9% อยู่ใน Theme ส่วน WordPress Core มีรายงานเพียง 6 รายการซึ่งเป็นระดับความสำคัญต่ำทั้งหมด
- 46% ของช่องโหว่ยังไม่มีแพตช์ในวันที่ถูกเปิดเผยต่อสาธารณะ
- สำหรับช่องโหว่ที่ถูกโจมตีหนัก ค่ามัธยฐานถ่วงน้ำหนักของเวลาจนถึงการโจมตีครั้งแรกคือ 5 ชั่วโมง และช่องโหว่ผลกระทบสูงราวครึ่งหนึ่งถูกโจมตีภายใน 24 ชั่วโมง
ตัวเลขเหล่านี้หมายความว่า เว็บที่ “ไม่มีอะไรให้ขโมย” ก็ถูกโจมตีได้ เพราะการโจมตีส่วนใหญ่เป็นแบบอัตโนมัติและเลือกเป้าจากเวอร์ชันของ Plugin ไม่ใช่จากความสำคัญของเว็บ เมื่อเจาะได้แล้ว เว็บจะถูกใช้เป็นฐานทำ SEO Spam พาผู้เข้าชมไปเว็บอื่น หรือส่งอีเมล Spam รายละเอียดของช่องโหว่แต่ละชนิดอยู่ใน ช่องโหว่ WordPress ที่พบบ่อยที่สุด 2026 และสาเหตุเชิงพฤติกรรมอยู่ใน ทำไม WordPress ถึงติดไวรัสบ่อย
อันตรายของธีมและปลั๊กอินเถื่อน (Nulled)
Theme หรือ Plugin เถื่อน (nulled, cracked, pirated) คือสำเนาของ Theme หรือ Plugin แบบเสียเงินที่ถูกบุคคลที่สามแก้ไขเพื่อตัดการตรวจสอบสิทธิ์การใช้งานออก แล้วนำมาแจกหรือขายต่อ บทความของ Sucuri (2023) สรุปความเสี่ยงไว้ 4 ด้าน
- Backdoor: บางชุดมี Backdoor ซ่อนไว้ ซึ่งใช้ขโมยข้อมูลลูกค้า ข้อมูลล็อกอิน ฝังตัวขโมยบัตรเครดิต หรือสร้างผู้ใช้ใหม่ได้
- มัลแวร์และ SEO Spam: ผู้แจกมักหารายได้ด้วยการฝังลิงก์ซ่อนหรือสคริปต์โฆษณา
- ช่องโหว่: ไฟล์ที่ถูกแก้อาจมีช่องโหว่เพิ่มเข้ามา
- ไม่ได้รับอัปเดต: สำเนาเถื่อนไม่ได้รับอัปเดตหรือแพตช์ความปลอดภัยจากผู้พัฒนาตัวจริง
ในบทความเดียวกัน Sucuri ทดลองดาวน์โหลด Theme เถื่อนจากเว็บที่ติดอันดับต้นในผลค้นหา และพบไฟล์ที่ซ่อน Web Shell แบบเข้ารหัสไว้ ซึ่งสามารถปิด Security Plugin แพร่ไปยังไฟล์อื่นบนเซิร์ฟเวอร์ และส่งข้อมูลฐานข้อมูลจาก wp-config.php ออกไปยังเซิร์ฟเวอร์ภายนอก (Sucuri, 2023) ข้อแนะนำของ Hardening WordPress จึงเขียนไว้ตรงๆ ว่าไม่ควรติดตั้ง Plugin หรือ Theme จากแหล่งที่ไม่น่าเชื่อถือ ให้ใช้จากคลังของ WordPress.org หรือบริษัทที่เป็นที่รู้จักเท่านั้น
อีกประเด็นที่ควรรู้คือ Plugin แบบเสียเงินของแท้ก็ไม่ได้ปลอดภัยโดยอัตโนมัติ Patchstack รายงานว่าในปี 2025 ได้รับรายงานช่องโหว่ใน Plugin และ Theme แบบ Premium หรือ Freemium 1,983 รายการ คิดเป็น 29% ของรายงานทั้งหมด และ 76% ของช่องโหว่ในกลุ่ม Premium ถูกจัดว่านำไปโจมตีได้จริง (Patchstack, 2026) ความต่างจึงอยู่ที่ของแท้ได้รับแพตช์จากผู้พัฒนา แต่ของเถื่อนไม่ได้ เมื่อ Backdoor จาก Plugin เถื่อนเข้าไปแล้ว การลบ Plugin ทิ้งอย่างเดียวมักไม่พอ อ่านเหตุผลได้ที่ Backdoor ใน WordPress คืออะไร ทำไมล้างไวรัสแล้วกลับมาติดซ้ำ
Checklist ความปลอดภัยที่ทำได้ทันที
ตารางนี้สรุปมาตรการหลักพร้อมเหตุผลและแหล่งอ้างอิง หัวข้อย่อยด้านล่างอธิบายวิธีทำของแต่ละข้อ
| มาตรการ | ป้องกันอะไร | แหล่งอ้างอิง |
|---|---|---|
| อัปเดต Core, Plugin, Theme และลบตัวที่ไม่ใช้ | การเจาะผ่านช่องโหว่ที่มีแพตช์แล้ว | WordPress.org Hardening |
| รหัสผ่านยาว ไม่ซ้ำ ใช้ Password Manager | การสุ่มรหัสผ่านและการใช้รหัสที่รั่วจากที่อื่น | NIST SP 800-63B, WordPress.org |
| เปิด 2FA ให้ทุกบัญชีแอดมิน | การล็อกอินด้วยรหัสผ่านที่รั่ว | WordPress.org, CISA |
| จำกัดความถี่การล็อกอิน และปิด XML-RPC ถ้าไม่ใช้ | Brute Force | WordPress.org |
| ใช้ HTTPS และ SFTP | การดักรหัสผ่านระหว่างทาง | WordPress.org Hardening |
| ใช้ WAF เป็นชั้นป้องกันเสริม | Request อันตรายก่อนถึงเว็บ | WordPress.org, Patchstack |
สิทธิ์ไฟล์ 755/644, wp-config.php 400 หรือ 440, ปิดการแก้ไฟล์จากหลังบ้าน |
การแก้ไฟล์และฝัง Backdoor | WordPress.org Hardening |
| Backup แบบ 3-2-1 และทดสอบกู้คืน | ความเสียหายถาวรเมื่อถูกเจาะหรือโดน Ransomware | CISA, WordPress.org |
1. อัปเดต WordPress, Plugin และ Theme และลบตัวที่ไม่ใช้
คู่มือ Hardening WordPress ระบุว่า WordPress เวอร์ชันเก่าไม่ได้รับการดูแลด้วยอัปเดตความปลอดภัยอีกต่อไป และแนะนำให้อัปเดต Plugin เสมอ รวมทั้งลบ Plugin ที่ไม่ได้ใช้ออกจากระบบ ไม่ใช่แค่ปิดการใช้งาน เพราะไฟล์ที่ยังอยู่บนเซิร์ฟเวอร์ยังเรียกได้จากภายนอก วิธีทำคือเข้า Dashboard → Updates อย่างสม่ำเสมอ เปิดอัปเดตอัตโนมัติให้ Plugin ที่ไม่กระทบการทำงานหลัก และทดสอบ Plugin สำคัญบนเว็บสำเนา (staging) ก่อนอัปเดตเว็บจริง ข้อมูลของ Patchstack ที่ว่าช่องโหว่ร้ายแรงถูกโจมตีภายในไม่กี่ชั่วโมงบอกว่าการรอรวบอัปเดตไว้ทำเดือนละครั้งนั้นช้าเกินไปสำหรับ Plugin ที่มีช่องโหว่ร้ายแรง ดูเพิ่มที่ ทำไมต้องอัปเดต Plugin และ Theme ใน WordPress
2. รหัสผ่าน: เน้นความยาวและไม่ใช้ซ้ำ
แนวทางล่าสุดของ NIST SP 800-63B (หัวข้อ 3.1.1.2) เปลี่ยนจากกฎ “ต้องมีตัวใหญ่ ตัวเลข อักขระพิเศษ” มาเน้นความยาวและการตรวจรหัสที่รั่ว สาระสำคัญคือ
- รหัสผ่านที่ใช้เป็นปัจจัยยืนยันตัวตนเพียงอย่างเดียวต้องยาวอย่างน้อย 15 ตัวอักษร ถ้าใช้ร่วมกับ MFA อนุญาตให้สั้นลงได้แต่ต้องไม่น้อยกว่า 8 ตัวอักษร
- ระบบควรรองรับรหัสผ่านยาวอย่างน้อย 64 ตัวอักษร
- ไม่ควรบังคับกฎผสมชนิดตัวอักษร และไม่ควรบังคับเปลี่ยนรหัสผ่านเป็นรอบ
- ต้องตรวจรหัสผ่านใหม่กับรายการรหัสที่ใช้บ่อยหรือเคยรั่ว และต้องอนุญาตให้ใช้ Password Manager
คู่มือ Brute Force Attacks ของ WordPress.org แนะนำในทิศทางเดียวกัน คือใช้รหัสผ่านยาวที่ไม่ซ้ำกับที่อื่นหรือใช้วลีรหัสผ่าน และใช้ Password Manager ส่วนคู่มือ Hardening แนะนำให้หลีกเลี่ยงชื่อผู้ใช้ที่เดาง่าย เช่น admin หรือ webmaster เพราะมักถูกลองก่อน หลักเดียวกันนี้ใช้กับรหัสผ่านของ Hosting, FTP/SFTP และฐานข้อมูลด้วย ไม่ใช่เฉพาะหน้า wp-admin
3. เปิด 2FA ให้ทุกบัญชีที่มีสิทธิ์สูง
WordPress.org แนะนำให้เปิด 2FA ให้ผู้ดูแลระบบและบัญชีที่มีสิทธิ์สูงทุกบัญชี และระบุว่า WordPress Core ไม่มี 2FA ในตัว ต้องใช้ Plugin หรือระบบยืนยันตัวตนภายนอก รวมทั้งแนะนำให้พิจารณา Passkey (WebAuthn) ซึ่งทนต่อ phishing (WordPress.org) CISA อธิบายว่าผู้ใช้ที่เปิด MFA มีโอกาสถูกแฮกน้อยลงอย่างมีนัยสำคัญ เพราะแม้ผู้โจมตีได้รหัสผ่านไปก็ยังผ่านปัจจัยที่สองไม่ได้ และระบุว่า FIDO/WebAuthn เป็นวิธียืนยันตัวตนที่ทนต่อ phishing ซึ่งใช้งานได้แพร่หลายเพียงวิธีเดียวในปัจจุบัน ความต่างของ 2FA แต่ละแบบอธิบายไว้ใน 2FA คืออะไร
4. จำกัดการล็อกอินและจัดการ XML-RPC
WordPress.org แนะนำให้จำกัดความถี่การล็อกอินที่ระดับ WAF/CDN หรือเว็บเซิร์ฟเวอร์ก่อน ถ้าทำไม่ได้จึงใช้ Security Plugin หน่วงการล็อกอิน เพราะ Plugin ยังทำงานภายใน PHP และกินทรัพยากรเมื่อถูกโจมตีหนัก สำหรับ xmlrpc.php ซึ่งถูกใช้สุ่มรหัสผ่านบ่อย ให้ปิดถ้าไม่ได้ใช้ ถ้ายังต้องใช้ (เช่น Jetpack หรือแอปมือถือ) ให้จำกัดด้วยกฎ WAF และจำกัดความถี่ คู่มือเดียวกันระบุด้วยว่าการเปลี่ยน URL หน้าล็อกอินช่วยลดสัญญาณรบกวนได้ แต่ไม่ควรเป็นการป้องกันเพียงชั้นเดียว (WordPress.org) อ่านต่อที่ Brute Force Attack คืออะไร และ XML-RPC คืออะไร ควรปิดไหม ส่วนวิธีตั้งค่าจำกัดการล็อกอินใน Wordfence อยู่ใน วิธีตั้งค่า Wordfence ทีละขั้น
5. ใช้ HTTPS และ SFTP
คู่มือ Hardening WordPress ระบุว่าการบังคับใช้ HTTPS กับส่วนผู้ดูแลระบบทำให้การสื่อสารและข้อมูลสำคัญถูกเข้ารหัส และแนะนำให้ใช้ SFTP แทน FTP เพราะ SFTP เข้ารหัสรหัสผ่านระหว่างส่ง จึงดักจับระหว่างทางไม่ได้ ถ้าไม่แน่ใจว่า Hosting รองรับ SFTP หรือไม่ ให้สอบถามผู้ให้บริการ ข้อนี้ทำครั้งเดียวแต่มีผลตลอด และควรเลิกใช้ FTP แบบไม่เข้ารหัสทุกบัญชี
6. ใช้ WAF เป็นชั้นเสริม ไม่ใช่ตัวแทนการอัปเดต
WAF (Web Application Firewall) กรอง request อันตรายก่อนถึง WordPress คู่มือ Hardening อธิบายว่ามีทั้งแบบที่ทำงานระดับเว็บเซิร์ฟเวอร์ แบบ Plugin ที่ทำงานระหว่าง WordPress โหลด และบริการแบบ reverse proxy ที่กรองทราฟฟิกก่อนถึงเซิร์ฟเวอร์ (WordPress.org) อย่างไรก็ตาม WAF ทั่วไปไม่ได้กันช่องโหว่ของ Plugin ได้ทั้งหมด Patchstack ทดสอบการป้องกันของผู้ให้บริการ Hosting ในปี 2025 และพบว่าการป้องกันแบบดั้งเดิมบล็อกการโจมตีช่องโหว่เฉพาะ WordPress ได้เพียง 12% ในการทดสอบชุดแรก และบล็อกได้ 26% ของการโจมตีทั้งหมดในการทดสอบชุดที่สอง โดยเฉพาะช่องโหว่กลุ่ม Broken Access Control ที่ request ดูเหมือนทราฟฟิกปกติของผู้ใช้ที่ล็อกอินแล้ว (Patchstack, 2026) ข้อสรุปคือ WAF ช่วยลดความเสี่ยงได้ แต่ยังต้องอัปเดตเร็วควบคู่กันเสมอ ส่วนคำถามว่าควรติดตั้ง Security Plugin หรือไม่ ดูที่ Security Plugin จำเป็นไหมสำหรับ WordPress
7. สิทธิ์ไฟล์ wp-config.php และการแก้ไฟล์จากหลังบ้าน
คู่มือ Hardening WordPress แนะนำสิทธิ์โฟลเดอร์ 755 และไฟล์ 644 ส่วน wp-config.php ซึ่งเก็บรหัสผ่านฐานข้อมูล ควรให้เฉพาะเจ้าของและเว็บเซิร์ฟเวอร์อ่านได้ ซึ่งโดยทั่วไปหมายถึงสิทธิ์ 400 หรือ 440 คู่มือเดียวกันแนะนำให้ปิดตัวแก้ไขไฟล์ Theme และ Plugin ในหน้าแอดมิน เพราะถ้าบัญชีแอดมินถูกยึด ผู้โจมตีจะใช้หน้านี้ฝังโค้ดได้ทันที โดยเพิ่มบรรทัดนี้ใน wp-config.php
define( 'DISALLOW_FILE_EDIT', true );สำหรับฐานข้อมูล คู่มือระบุว่าการทำงานปกติของ WordPress ต้องการเพียงสิทธิ์ SELECT, INSERT, UPDATE และ DELETE สิทธิ์ระดับโครงสร้างอย่าง DROP, ALTER และ GRANT จึงเพิกถอนได้ แต่ต้องคืนสิทธิ์ชั่วคราวเมื่ออัปเดตใหญ่หรือติดตั้ง Plugin ที่ต้องสร้างตาราง ค่าสิทธิ์ไฟล์แบบละเอียดอยู่ใน File Permission ใน WordPress ตั้งค่าอย่างไรให้ปลอดภัย
8. ผู้ใช้และเครื่องของผู้ดูแล
ให้สิทธิ์ Administrator เฉพาะคนที่จำเป็น บัญชีของผู้รับจ้างที่ทำงานเสร็จแล้วควรลบหรือลดสิทธิ์ ความเสี่ยงของการมีแอดมินหลายคนอธิบายไว้ใน User Admin หลายคนใน WordPress เสี่ยงอย่างไร อีกจุดที่มักถูกมองข้ามคือคอมพิวเตอร์ของผู้ดูแลเว็บเอง คู่มือ Hardening เตือนว่าถ้าเครื่องที่ใช้ล็อกอินมี keylogger การตั้งค่าความปลอดภัยใน WordPress หรือบนเซิร์ฟเวอร์จะไม่ช่วยอะไรเลย และควรอัปเดตระบบปฏิบัติการกับเบราว์เซอร์เสมอ (WordPress.org)
ระบบ Backup ที่ดีควรเป็นอย่างไร
Backup ไม่ได้กันการถูกแฮก แต่เป็นสิ่งที่กำหนดว่าเว็บจะกลับมาได้เร็วแค่ไหนและเสียข้อมูลมากเท่าไร เอกสาร Data Backup Options ของ CISA แนะนำกฎ 3-2-1 คือ เก็บข้อมูลสำคัญ 3 ชุด (ต้นฉบับ 1 และสำรอง 2) บนสื่อ 2 ประเภท และเก็บนอกสถานที่ 1 ชุด เมื่อนำมาใช้กับ WordPress หมายถึงเว็บบนเซิร์ฟเวอร์ 1 ชุด Backup ของ Hosting 1 ชุด และ Backup ที่ส่งออกไปเก็บบนบริการอื่นนอกบัญชี Hosting อีก 1 ชุด
คุณภาพของ Backup สำคัญเท่ากับจำนวน คู่มือ Hardening WordPress แนะนำให้สำรองทั้งไฟล์และฐานข้อมูล เก็บ snapshot ของทั้งเว็บเป็นรอบ และเพิ่มความมั่นใจว่า Backup ไม่ถูกแก้ด้วยการเข้ารหัส บันทึกค่า hash ของไฟล์ไว้แยก หรือเก็บบนสื่อแบบอ่านอย่างเดียว ส่วน #StopRansomware Guide ของ CISA แนะนำให้เก็บ Backup แบบออฟไลน์และเข้ารหัส และทดสอบการกู้คืนเป็นประจำ เพราะ Ransomware หลายตัวค้นหาและทำลาย Backup ที่เข้าถึงได้
- ความถี่: ตามความถี่ที่ข้อมูลเปลี่ยน เว็บที่มีออเดอร์ทุกวันควรสำรองฐานข้อมูลทุกวัน
- ระยะเก็บย้อนหลัง: เก็บหลายรุ่นย้อนหลัง เพราะเว็บอาจถูกเจาะมาก่อนที่จะเห็นอาการ Backup ล่าสุดอาจติดมัลแวร์ไปแล้ว
- ทดสอบกู้คืน: Backup ที่ไม่เคยกู้คืนดูยังพิสูจน์ไม่ได้ว่าใช้งานได้
ขั้นตอนตั้งค่าแบบละเอียดอยู่ใน ควรทำ Backup WordPress อย่างไรให้ปลอดภัย และภัยที่ทำให้ Backup สำคัญที่สุดอธิบายไว้ใน Botnet และ Ransomware บนเซิร์ฟเวอร์
เลือกโฮสติ้งอย่างไรให้ปลอดภัย
Hosting เป็นชั้นที่เจ้าของเว็บควบคุมได้น้อยที่สุด แต่มีผลมาก คู่มือ Hardening WordPress เตือนว่าบน shared server ถ้าเว็บอื่นบนเซิร์ฟเวอร์เดียวกันถูกเจาะ เว็บของคุณก็อาจถูกเจาะตามได้ แม้จะทำตามคู่มือครบทุกข้อ และแนะนำให้สอบถาม Hosting ว่ามีมาตรการความปลอดภัยอะไรบ้าง หน้า Requirements ของ WordPress.org แนะนำ PHP 8.3 ขึ้นไป, MySQL 8.0 ขึ้นไปหรือ MariaDB 10.11 ขึ้นไป และการรองรับ HTTPS พร้อมเตือนว่า PHP และ MySQL รุ่นเก่าที่หมดอายุการสนับสนุนแล้วอาจทำให้เว็บมีช่องโหว่
คำถามที่ควรถาม Hosting ก่อนเลือกหรือย้าย
- แต่ละเว็บหรือแต่ละบัญชีถูกแยกสิทธิ์กันหรือไม่ (เว็บหนึ่งถูกเจาะแล้วอ่านไฟล์อีกเว็บได้หรือไม่)
- เลือก PHP เวอร์ชันที่ยังได้รับการสนับสนุนได้หรือไม่
- รองรับ SFTP หรือ SSH และใบรับรอง HTTPS หรือไม่
- มี Backup อัตโนมัติ เก็บย้อนหลังกี่วัน และเก็บแยกจากเซิร์ฟเวอร์หลักหรือไม่
- มี WAF หรือการสแกนมัลแวร์ฝั่งเซิร์ฟเวอร์หรือไม่ และถ้าพบปัญหาจะแจ้งอย่างไร
สำหรับร้านค้าออนไลน์ที่รับบัตรเครดิต ความเสี่ยงเพิ่มอีกระดับ เพราะโค้ดที่ถูกฝังในหน้า Checkout ขโมยข้อมูลบัตรได้โดยไม่มีใครเห็น อ่านต่อที่ Magecart คืออะไร
การดูแลรายเดือน (Maintenance)
คู่มือ Hardening WordPress ระบุว่าบางครั้งการป้องกันอย่างเดียวไม่พอ การเฝ้าระวังจึงสำคัญ เพราะการโจมตีทุกครั้งทิ้งร่องรอยไว้ใน log หรือในระบบไฟล์ เช่น ไฟล์ใหม่หรือไฟล์ที่ถูกแก้ การตรวจความเปลี่ยนแปลงของไฟล์และการอ่าน log ช่วยให้รู้ตัวเร็ว รู้ว่าเกิดอะไรขึ้น และกู้คืนได้เร็วกว่า งานเหล่านี้ต้องทำต่อเนื่อง ไม่ใช่ตั้งค่าครั้งเดียว ตัวอย่างงานประจำที่ควรมี
- ทุกสัปดาห์: อัปเดต Plugin, Theme และ Core หลังทดสอบ และดูผลสแกนของ Security Plugin
- ทุกเดือน: ทบทวนรายชื่อผู้ใช้และสิทธิ์ ลบ Plugin ที่ไม่ใช้ ตรวจรายงาน Security issues ใน Google Search Console และทดลองกู้คืน Backup
- ทุกไตรมาส: ทบทวนบัญชีที่แชร์รหัสผ่านกับผู้อื่น และเปลี่ยนรหัสผ่านทันทีเมื่อมีคนออกจากทีมหรือมีสัญญาณว่ารั่ว ตรวจเวอร์ชัน PHP และทบทวนสิทธิ์ไฟล์
จากเคสที่เราแก้ เว็บที่ถูกเจาะส่วนใหญ่ไม่ได้ขาดเครื่องมือ แต่ขาดคนที่ทำงานเหล่านี้อย่างสม่ำเสมอ ถ้าไม่มีเวลาดูแลเอง WP Doctor Thailand มีบริการ ดูแลเว็บไซต์ WordPress รายเดือน ที่ครอบคลุมการอัปเดต สำรองข้อมูล และเฝ้าระวังความปลอดภัย ถ้าเว็บถูกเจาะไปแล้ว ให้เริ่มจาก เว็บ WordPress โดนแฮก ต้องทำอะไรก่อน
คำถามที่พบบ่อย
ป้องกันเว็บโดนแฮกได้ 100% ไหม?
ไม่มีมาตรการใดรับประกันได้ เพราะช่องโหว่ใหม่ถูกค้นพบตลอด และบางช่องโหว่ยังไม่มีแพตช์ในวันที่ถูกเปิดเผย เป้าหมายที่เป็นจริงคือลดโอกาสให้ต่ำที่สุด และกู้คืนได้เร็วถ้าเกิดเหตุ
ควรเริ่มทำข้อไหนก่อน ถ้ามีเวลาน้อย?
เริ่มจากอัปเดต Plugin และ Theme ลบตัวที่ไม่ใช้ เปิด 2FA ให้บัญชีแอดมิน และตั้ง Backup ที่ส่งออกไปเก็บนอก Hosting สามข้อนี้ครอบคลุมช่องทางเข้าหลักและการกู้คืน
Plugin เถื่อน (nulled) ถ้าสแกนแล้วไม่เจอไวรัส ใช้ได้ไหม?
ไม่แนะนำ เพราะโค้ดอันตรายมักถูกเข้ารหัสจนสแกนไม่พบ และสำเนาเถื่อนไม่ได้รับอัปเดตความปลอดภัยจากผู้พัฒนา WordPress.org แนะนำให้ใช้ Plugin และ Theme จากคลังของ WordPress.org หรือบริษัทที่เป็นที่รู้จักเท่านั้น
ต้องเปลี่ยนรหัสผ่านทุก 90 วันไหม?
NIST SP 800-63B ระบุว่าไม่ควรบังคับเปลี่ยนรหัสผ่านเป็นรอบ ให้เปลี่ยนเมื่อมีหลักฐานว่ารหัสรั่ว และเน้นใช้รหัสผ่านยาวที่ไม่ซ้ำกับที่อื่นร่วมกับ 2FA แทน
มี Security Plugin แล้ว ยังต้องทำข้ออื่นอีกไหม?
ต้องทำ Security Plugin ช่วยเรื่องสแกนและจำกัดการล็อกอิน แต่ไม่ได้อัปเดต Plugin แทนคุณ ไม่ได้ตั้งสิทธิ์ไฟล์ และไม่ได้ทำ Backup นอกเซิร์ฟเวอร์ ดูวิธีตั้งค่าที่ วิธีตั้งค่า Wordfence ทีละขั้น
wp-config.php ควรตั้ง permission เท่าไร?
คู่มือ Hardening ของ WordPress.org แนะนำให้มีเพียงเจ้าของไฟล์และเว็บเซิร์ฟเวอร์ที่อ่านได้ ซึ่งโดยทั่วไปคือ 400 หรือ 440 ถ้าตั้งแล้วเว็บใช้งานไม่ได้ ให้สอบถาม Hosting ว่าเว็บเซิร์ฟเวอร์รันด้วยผู้ใช้ใด
แหล่งอ้างอิง
- W3Techs. (2026). Usage statistics and market share of WordPress. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://w3techs.com/technologies/details/cm-wordpress
- Patchstack. (2026). State of WordPress Security in 2026. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/
- WordPress.org. (ม.ป.ป.). Hardening WordPress — Advanced Administration Handbook. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/security/hardening/
- WordPress.org. (ม.ป.ป.). Brute Force Attacks — Advanced Administration Handbook. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/security/brute-force/
- WordPress.org. (ม.ป.ป.). Requirements. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/about/requirements/
- Chaddock, N. (2023). The Dangers of Installing Nulled WordPress Themes & Plugins. Sucuri Blog. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://blog.sucuri.net/2023/02/the-dangers-of-installing-nulled-wordpress-themes-and-plugins.html
- National Institute of Standards and Technology. (2025). NIST SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://pages.nist.gov/800-63-4/sp800-63b.html
- Cybersecurity and Infrastructure Security Agency. (ม.ป.ป.). More than a Password (Multifactor Authentication). สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.cisa.gov/MFA
- Ruggiero, P., & Heckathorn, M. A. (ม.ป.ป.). Data Backup Options. Cybersecurity and Infrastructure Security Agency. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.cisa.gov/sites/default/files/publications/data_backup_options.pdf
- Cybersecurity and Infrastructure Security Agency. (2023). #StopRansomware Guide. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.cisa.gov/stopransomware/ransomware-guide
