Magecart คืออะไร? ภัยขโมยข้อมูลบัตรเครดิตที่เว็บ E-commerce ต้องระวัง

Magecart คือชื่อเรียกการโจมตีที่ฝังโค้ด JavaScript ลงในหน้าเว็บร้านค้าออนไลน์ เพื่อคัดลอกข้อมูลบัตรเครดิตและข้อมูลส่วนบุคคลที่ลูกค้ากรอกตอนชำระเงิน แล้วส่งออกไปยังเซิร์ฟเวอร์ของผู้โจมตี โดยที่ร้านค้าและลูกค้าไม่รู้ตัว ในเอกสารมาตรฐานมักเรียกการโจมตีแบบนี้ว่า Online Skimming, E-skimming หรือ Credit Card Skimmer บนเว็บไซต์

คำสั่งซื้อยังเข้าระบบตามปกติ เงินยังเข้าบัญชีร้าน หน้าเว็บก็ดูเหมือนเดิม การโจมตีนี้จึงมักถูกพบช้า บทความนี้เป็นส่วนหนึ่งของชุดบทความ มัลแวร์เว็บไซต์คืออะไร มีกี่แบบ และต่อยอดจากเรื่อง Malicious JavaScript และ iFrame Injection ซึ่งเป็นกลไกพื้นฐานของ Magecart

Credit Card Skimmer และ Magecart คืออะไร

วารสารร่วมเรื่อง The Threat of Online Skimming to Payment Security ของ PCI Security Standards Council (PCI SSC) และ Retail & Hospitality ISAC (RH-ISAC) เผยแพร่เมื่อ 1 สิงหาคม 2019 อธิบายว่า Online Skimming คือการติดโค้ดอันตรายที่เรียกว่า sniffer หรือ JavaScript sniffer ให้เว็บ E-commerce ซึ่งตรวจจับได้ยากมาก เมื่อเว็บติดแล้ว ข้อมูลบัตรจะถูก “skim” ระหว่างทำรายการโดยที่ทั้งร้านค้าและผู้บริโภคไม่รู้ว่าข้อมูลรั่วไหล

เอกสารฉบับเดียวกันระบุว่า Magecart เป็นคำที่สื่อมวลชนใช้ และนักวิจัยด้านความปลอดภัยบางส่วนใช้เป็นคำเรียกรวมของกลุ่มอาชญากรหลายกลุ่มที่อยู่เบื้องหลังการโจมตีแบบ Online Skimming รวมทั้งใช้เรียกรูปแบบการโจมตีนั้นเอง และระบุว่าการโจมตีลักษณะนี้มีมาตั้งแต่ปี 2015 Magecart จึงไม่ใช่มัลแวร์ตัวเดียว แต่เป็นชื่อของประเภทการโจมตี

คู่มือ Preparing for a Cyber Incident: A Guide to e-Skimming ของ U.S. Secret Service อธิบายในทำนองเดียวกันว่าผู้โจมตีใส่โค้ดอันตรายในหน้าเว็บที่ประมวลผลการชำระเงินด้วยบัตร เพื่อเก็บข้อมูลระบุตัวบุคคลและข้อมูลบัตร แล้วส่งไปยังโดเมนที่ตนควบคุม

ทำไมเว็บ E-commerce เป็นเป้าหมาย

หน้า Checkout คือจุดที่ข้อมูลมีมูลค่าสูงที่สุดของเว็บถูกพิมพ์ลงในเบราว์เซอร์ วารสารของ PCI SSC และ RH-ISAC ระบุว่าโค้ดมักทำงานเมื่อผู้ซื้อกดส่งข้อมูลชำระเงิน ข้อมูลที่ผู้โจมตีแต่ละกลุ่มเก็บแตกต่างกัน ได้แก่ ที่อยู่สำหรับออกใบแจ้งหนี้ ชื่อ อีเมล เบอร์โทรศัพท์ ข้อมูลบัตรเครดิต ชื่อผู้ใช้ และรหัสผ่าน จากนั้นโค้ดจะบันทึกข้อมูลไว้บนเว็บที่ถูกแฮก หรือส่งไปยังเครื่องที่ผู้โจมตีควบคุม

วารสารฉบับเดียวกันระบุช่องทางที่ผู้โจมตีใช้เข้าถึงเว็บ ดังนี้

• ปลั๊กอินที่มีช่องโหว่ และซอฟต์แวร์เว็บที่ยังไม่ได้อัปเดตแพตช์
• การเดารหัสผ่านด้วยข้อมูลที่รั่วจากที่อื่น (credential stuffing) รวมถึง phishing และ social engineering
• สคริปต์ของผู้ให้บริการภายนอก เช่น สคริปต์โฆษณา แชตสด และระบบรีวิวสินค้า เมื่อผู้ให้บริการรายหนึ่งถูกเจาะ ผู้โจมตีจะฝังโค้ดเข้าไปในเว็บทุกเว็บที่ใช้สคริปต์นั้นได้พร้อมกัน

ประเด็นเรื่องสคริปต์ภายนอกนี้ คู่มือความปลอดภัยของ Stripe อธิบายไว้ตรงกันว่า การโหลด JavaScript จากเว็บอื่นทำให้ความปลอดภัยของเว็บเราขึ้นกับความปลอดภัยของเว็บนั้น ถ้าเว็บนั้นถูกเจาะ ผู้โจมตีจะรันโค้ดใดก็ได้บนหน้าเว็บของเรา

วารสารของ PCI SSC ยังอ้างรายงานของนักวิจัยว่าร้านค้าที่ติด Magecart ประมาณ 1 ใน 5 ถูกฝังซ้ำภายในไม่กี่วัน และเน้นว่าต้องล้างระบบและปิดช่องโหว่ต้นเหตุ ไม่เช่นนั้นโค้ดที่เหลือหรือช่องโหว่เดิมจะนำไปสู่การติดซ้ำ ซึ่งเป็นกลไกเดียวกับที่อธิบายไว้ในบทความ Backdoor ใน WordPress ทำไมล้างแล้วติดซ้ำ

กรณีศึกษา: British Airways (2018)

เหตุการณ์ที่มีเอกสารทางการละเอียดที่สุดกรณีหนึ่งคือ Penalty Notice ที่สำนักงาน Information Commissioner’s Office (ICO) ของสหราชอาณาจักรออกให้ British Airways ลงวันที่ 16 ตุลาคม 2020 สาระสำคัญตามเอกสารมีดังนี้

• ระหว่าง 22 มิถุนายน ถึง 5 กันยายน 2018 ผู้โจมตีเข้าสู่ระบบภายในของ BA โดยใช้ข้อมูลล็อกอินที่ถูกขโมยของระบบเข้าถึงระยะไกล (Citrix) แล้วเคลื่อนที่ต่อในเครือข่าย
• ผู้โจมตีแก้ไขไฟล์ JavaScript บนเว็บไซต์ britishairways.com ให้ส่งข้อมูลบัตรของลูกค้าไปยังโดเมน BAways.com ที่ผู้โจมตีควบคุม ชื่อโดเมนตั้งให้คล้ายของจริงเพื่อไม่ให้สะดุดตา
• โค้ดทำงานอยู่บนเว็บ 15 วัน ระหว่าง 21 สิงหาคม ถึง 5 กันยายน 2018 โดยการจองและชำระเงินของลูกค้ายังดำเนินไปตามปกติ
• BA ทราบเหตุเมื่อบุคคลภายนอกแจ้งว่ามีข้อมูลถูกส่งจากเว็บไปยัง BAways.com และแจ้ง ICO ในวันรุ่งขึ้น
• ข้อมูลของบุคคลราว 429,612 รายอาจถูกเข้าถึง ในจำนวนนี้ 244,000 รายเป็นชื่อ ที่อยู่ หมายเลขบัตร และ CVV
• ICO สรุปว่า BA ไม่ได้ใช้มาตรการทางเทคนิคและการจัดการที่เหมาะสมตาม Article 5(1)(f) และ Article 32 ของ GDPR และกำหนดค่าปรับสุดท้าย 20 ล้านปอนด์

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

ความรับผิดชอบทางกฎหมายและมาตรฐาน

หัวข้อนี้สรุปเฉพาะสิ่งที่เอกสารต้นฉบับระบุไว้ ไม่ใช่คำแนะนำทางกฎหมาย หากเกิดเหตุจริงควรปรึกษาผู้เชี่ยวชาญด้านกฎหมาย

PDPA: หน้าที่แจ้งเหตุภายใน 72 ชั่วโมง

ข้อมูลที่ Skimmer เก็บ เช่น ชื่อ ที่อยู่ อีเมล และข้อมูลบัตร เป็นข้อมูลส่วนบุคคล ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 ซึ่งออกโดยอาศัยอำนาจตามมาตรา 16 (4) ประกอบมาตรา 37 (4) แห่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 และประกาศในราชกิจจานุเบกษาเมื่อ 15 ธันวาคม 2565 กำหนดไว้ว่า

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

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

PCI DSS: Requirement 6.4.3 และ 11.6.1

PCI DSS คือมาตรฐานความปลอดภัยของอุตสาหกรรมบัตรชำระเงิน ในเวอร์ชัน 4.0.1 มีข้อกำหนด 2 ข้อที่ออกแบบมาเพื่อรับมือ E-skimming โดยตรง ตามบทความของ PCI SSC ที่ประกาศเอกสารแนวทาง Payment Page Security and Preventing E-Skimming เมื่อมีนาคม 2025 ข้อกำหนดทั้งสองมุ่งให้สคริปต์บนหน้าชำระเงินได้รับอนุญาตอย่างถูกต้อง มีการตรวจความถูกต้องของสคริปต์ และมีการเฝ้าระวังการถูกแก้ไข รวมถึงการจัดการ HTTP header ที่มีผลต่อความปลอดภัย

• 6.4.3 FAQ 1581 ของ PCI SSC ระบุว่าวัตถุประสงค์ของข้อนี้คือทำให้โค้ดที่ไม่ได้รับอนุญาตรันบนหน้าชำระเงินในเบราว์เซอร์ของผู้บริโภคไม่ได้
• 11.6.1 ว่าด้วยกลไกตรวจจับและแจ้งเตือนเมื่อสคริปต์หรือ security header ของหน้าชำระเงินถูกเปลี่ยนแปลงโดยไม่ได้รับอนุญาต

ตามประกาศของ PCI SSC เมื่อ 30 มกราคม 2025 ข้อกำหนดเหล่านี้มีผลบังคับตั้งแต่ 31 มีนาคม 2025 ในประกาศเดียวกัน PCI SSC ถอดข้อ 6.4.3 และ 11.6.1 ออกจากแบบประเมินตนเอง SAQ A แต่เพิ่มเงื่อนไขคุณสมบัติให้ร้านค้ายืนยันว่าเว็บของตน “ไม่เสี่ยงต่อการโจมตีจากสคริปต์ที่อาจกระทบระบบ E-commerce ของร้าน” และระบุชัดว่าการเปลี่ยนแปลงนี้ไม่ได้ลดทอนข้อกำหนดใน PCI DSS เอง

ฝั่ง WooCommerce เอกสาร PCI-DSS and WooCommerce ระบุว่า WooCommerce ไม่เก็บรายละเอียดบัตร และแม้จะใช้ gateway ที่รับชำระนอกเว็บหรือใช้ hosted fields ซึ่งเว็บไม่ได้แตะข้อมูลบัตรดิบโดยตรง PCI DSS ก็ยังเกี่ยวข้อง เพราะเว็บของร้านยังเป็นผู้แสดงหน้า Checkout เพียงแต่ขอบเขตอาจลดลงมาก เอกสารเดียวกันระบุว่าการปฏิบัติตาม PCI DSS เป็นความรับผิดชอบของเจ้าของร้านในท้ายที่สุด

รูปแบบการรับชำระเงินใน WooCommerce กับความเสี่ยง

ร้านที่ใช้ WooCommerce เลือกรูปแบบการรับบัตรได้หลายแบบ แต่ละแบบให้ผลต่างกันต่อการโจมตีแบบ Skimming ตารางนี้สรุปจากเอกสารของ WooCommerce, Stripe และ FAQ 1588 ของ PCI SSC ซึ่งระบุว่าเงื่อนไขเรื่องสคริปต์ของ SAQ A ใช้กับร้านที่ฝังฟอร์มชำระเงินผ่าน iframe และไม่ใช้กับร้านที่ redirect ลูกค้าไปยังหน้าของผู้ให้บริการชำระเงิน

ช่องทางที่ไม่ต้องกรอกเลขบัตร เช่น QR พร้อมเพย์ ไม่มีข้อมูลบัตรให้ Skimmer เก็บ แต่ข้อมูลส่วนบุคคลในหน้า Checkout ยังต้องได้รับการป้องกันเช่นเดิม ถ้าระบบชำระเงินของร้านมีปัญหาด้านการตั้งค่าอยู่แล้ว ดูเพิ่มที่ Payment Gateway Error ใน WooCommerce และ WooCommerce Checkout ไม่ได้ เกิดจากอะไร

สัญญาณเตือนและวิธีตรวจสอบ

Skimmer ถูกออกแบบให้ไม่มีอาการที่หน้าเว็บ สัญญาณส่วนใหญ่จึงมาจากภายนอกหรือจากการตรวจเชิงรุก

• ลูกค้าหลายคนแจ้งว่าบัตรถูกใช้ผิดปกติหลังซื้อสินค้าจากร้าน หรือธนาคาร/ผู้ให้บริการชำระเงินติดต่อมาเรื่องข้อมูลบัตรรั่ว
• หน้า Checkout โหลดไฟล์ JavaScript หรือส่งคำขอไปยังโดเมนที่ไม่รู้จัก โดยเฉพาะโดเมนที่ตั้งชื่อคล้ายแบรนด์ร้านหรือบริการวิเคราะห์สถิติ ซึ่งเป็นลักษณะเดียวกับโดเมนในกรณีของ BA
• ไฟล์ JavaScript ของ Theme ปลั๊กอิน หรือ WooCommerce ถูกแก้ไขโดยไม่มีการอัปเดต
• พบบัญชีผู้ดูแลระบบที่ไม่รู้จัก หรือ Search Console แจ้ง Security Issues

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

# รันในโฟลเดอร์รากของ WordPress (อ่านอย่างเดียว ไม่แก้ไฟล์)
# ไฟล์ .js และ .php ที่ถูกแก้ไขใน 14 วันล่าสุด
find wp-content -type f \( -name "*.js" -o -name "*.php" \) -mtime -14 -ls

# เทียบไฟล์ core และปลั๊กอินจาก WordPress.org กับต้นฉบับ
wp core verify-checksums
wp plugin verify-checksums --all

# ไฟล์ JavaScript ที่มีโค้ดเข้ารหัส ซึ่งโค้ดปกติของ Theme แทบไม่ใช้
grep -rlE "atob\(|fromCharCode|eval\(" wp-content/themes wp-content/plugins --include=*.js

-- ใน phpMyAdmin: ค่าตั้งค่าที่มี script (ช่อง Header/Footer ของ Theme หรือปลั๊กอิน)
SELECT option_id, option_name FROM wp_options
WHERE option_value LIKE '%<script%';

-- เนื้อหาบทความและหน้าที่มี script
SELECT ID, post_title, post_type FROM wp_posts
WHERE post_content LIKE '%<script%';

-- บัญชีผู้ดูแลระบบทั้งหมด (ตรวจว่ามีบัญชีที่ไม่รู้จักหรือไม่)
SELECT u.ID, u.user_login, u.user_registered FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%';

ถ้าพบโค้ดน่าสงสัยบนหน้า Checkout อย่าเพิ่งลบทิ้งทันที ให้สำรองไฟล์และฐานข้อมูลสภาพปัจจุบันไว้เป็นหลักฐานก่อน เพราะข้อมูลนี้จำเป็นต่อการประเมินว่าโค้ดทำงานตั้งแต่เมื่อไรและกระทบลูกค้ากี่ราย ขั้นตอนรับมือโดยรวมอยู่ในบทความ เว็บ WordPress โดนแฮก ต้องทำอะไรก่อน

วิธีป้องกัน

วารสารของ PCI SSC และ RH-ISAC แนะนำการป้องกันหลายชั้น ซึ่งปรับใช้กับร้าน WooCommerce ได้ดังนี้

• เลือกรูปแบบชำระเงินที่ข้อมูลบัตรไม่ผ่านหน้าเว็บร้าน เช่น redirect ไปหน้าของผู้ให้บริการ หรือช่องกรอกบัตรแบบ iframe ที่โหลดจากผู้ให้บริการ เพื่อลดสิ่งที่สคริปต์บนเว็บร้านเข้าถึงได้
• อัปเดต WordPress, WooCommerce, Theme และปลั๊กอิน และลบปลั๊กอินที่ไม่ได้ใช้ วารสารระบุทั้งการติดตั้งแพตช์และการปิดปลั๊กอินที่ไม่จำเป็น เหตุผลเพิ่มเติมอยู่ที่ ทำไมต้องอัปเดต Plugin และ Theme
• จำกัดสคริปต์ภายนอกบนหน้าชำระเงิน วารสารแนะนำว่าไม่ควรอนุญาต JavaScript หรือ CSS ที่โฮสต์ภายนอกบนหน้ารับชำระ และถ้าเป็นไปได้ให้ใช้สำเนาที่โฮสต์เองแทนสคริปต์ของบุคคลที่สาม ในทางปฏิบัติคือปิดแชต ป๊อปอัปโฆษณา และสคริปต์ที่ไม่จำเป็นบนหน้า Checkout
• ใช้ Content Security Policy เพื่อจำกัดโดเมนที่หน้าเว็บโหลดสคริปต์และส่งข้อมูลไปได้ วารสารระบุ CSP เป็นมาตรการเสริม ส่วนวิธีตั้งค่าและข้อจำกัดอยู่ในบทความ JavaScript และ iFrame Injection Stripe เองก็เผยแพร่รายการ directive ที่ต้องอนุญาตสำหรับบริการของตนไว้ในคู่มือความปลอดภัย
• เปิด MFA ให้ทุกบัญชีที่เข้าถึงระบบร้าน วารสารอ้างถึง PCI DSS Requirement 8.3 สำหรับเรื่องนี้ วิธีเปิดใช้ใน WordPress ดูที่ 2FA คืออะไร
• เฝ้าระวังการเปลี่ยนแปลงไฟล์ วารสารระบุ file-integrity monitoring หรือซอฟต์แวร์ตรวจจับการเปลี่ยนแปลงเป็นมาตรการตรวจจับ ซึ่งสอดคล้องกับเจตนาของ Requirement 11.6.1

จากเคสที่เราแก้ ร้านค้าออนไลน์มักใช้ปลั๊กอินเสริมจำนวนมากบนหน้า Checkout ทั้งระบบส่วนลด ระบบสมาชิก และสคริปต์การตลาด ซึ่งแต่ละตัวเพิ่มจุดที่ต้องดูแล ถ้าต้องการให้ตรวจหน้า Checkout ล้างโค้ด และปรับระบบชำระเงินให้ปลอดภัยขึ้น ดูรายละเอียดบริการแก้ปัญหา WooCommerce และล้างไวรัสและมัลแวร์ WordPress

คำถามที่พบบ่อย

แหล่งอ้างอิง

1. PCI Security Standards Council & Retail and Hospitality ISAC. (2019). The Threat of Online Skimming to Payment Security. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://listings.pcisecuritystandards.org/pdfs/PCISSC_Magecart_Bulletin_RHISAC_FINAL.pdf
2. United States Secret Service. (2020). Preparing for a Cyber Incident: A Guide to e-Skimming. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.secretservice.gov/sites/default/files/reports/2020-12/Preparing%20for%20a%20Cyber%20Incident%20-%20A%20Guide%20to%20e-Skimming%20v%201.0.pdf
3. Information Commissioner’s Office. (2020). Penalty Notice: British Airways plc. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://ico.org.uk/media2/migrated/2618421/ba-penalty-20201016.pdf
4. สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล. (2565). ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.pdpc.or.th/2405/
5. สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล. (2565). ประกาศฯ เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 (ไฟล์ PDF ราชกิจจานุเบกษา). สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.pdpc.or.th/wp-content/uploads/2023/12/announce-15122565.pdf
6. PCI Security Standards Council. (2025). New Information Supplement: Payment Page Security and Preventing E-Skimming. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming
7. PCI Security Standards Council. (2025). Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
8. PCI Security Standards Council. (2024). FAQ 1581: How does PCI DSS Requirement 6.4.3 apply to 3DS scripts called from a merchant check-out page?. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.pcisecuritystandards.org/faqs/1581/
9. PCI Security Standards Council. (2025). FAQ 1588: How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.pcisecuritystandards.org/faqs/how-does-an-e-commerce-merchant-meet-the-saq-a-eligibility-criteria-for-scripts/
10. WooCommerce. (2025). PCI-DSS and WooCommerce. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://woocommerce.com/document/pci-dss-compliance-and-woocommerce/
11. Stripe. (ม.ป.ป.). Integration security guide. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://docs.stripe.com/security/guide
12. WordPress.org. (ม.ป.ป.). wp plugin verify-checksums — WP-CLI Commands. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/cli/commands/plugin/verify-checksums/