วิธีตรวจสอบความปลอดภัยเว็บไซต์ร้านค้าออนไลน์ได้เองโดยไม่ต้องเจาะระบบ

คุณตรวจสอบการตั้งค่าความปลอดภัยของร้านค้าออนไลน์ได้หลายส่วนจากภายนอก โดยอ่านสิ่งที่เว็บไซต์ส่งให้ผู้เข้าชมทุกคนอยู่แล้ว ได้แก่ ใบรับรอง TLS การเปลี่ยนเส้นทาง (redirect) ส่วนหัวการตอบกลับ HTTP (HTTP response header) คุกกี้ สคริปต์ที่โหลด และระเบียน DNS สาธารณะ การตรวจแบบ passive เหล่านี้ไม่ส่งทราฟฟิกโจมตีและไม่ต้องเข้าสู่ระบบ จึงไม่สร้างภาระให้ร้านมากไปกว่าการเข้าชมตามปกติ การตรวจนี้จับจุดบกพร่องในการตั้งค่าได้ เช่น ใบรับรองที่ใกล้หมดอายุ ไม่มี HSTS คุกกี้ที่ไม่ปลอดภัย mixed content หรือ jQuery รุ่นที่มีข้อบกพร่องที่ทราบกันแล้ว แต่การตรวจนี้ไม่ใช่การทดสอบเจาะระบบ (penetration test) และพิสูจน์ไม่ได้ว่าร้านปลอดภัย

ประเด็นสำคัญ

• ใบรับรอง TLS ที่เชื่อถือได้แบบสาธารณะซึ่งออกตั้งแต่วันที่ 15 มีนาคม 2026 มีอายุใช้งานได้ไม่เกิน 200 วัน และจะลดลงเหลือ 100 วันในเดือนมีนาคม 2027 และ 47 วันในเดือนมีนาคม 2029 (CA/Browser Forum (เปิดในแท็บใหม่))
• เบราว์เซอร์จะไม่สนใจส่วนหัว HSTS เมื่อส่งผ่าน HTTP ธรรมดา (MDN (เปิดในแท็บใหม่))
• คำสั่ง (directive) frame-ancestors ของ CSP ใช้ในแท็ก <meta> ไม่ได้ ต้องส่งเป็นส่วนหัวการตอบกลับเท่านั้น (MDN (เปิดในแท็บใหม่))
• jQuery รุ่นก่อน 3.5.0 ได้รับผลกระทบจากช่องโหว่ XSS 2 รายการ และ CISA ได้เพิ่มหนึ่งในนั้นคือ CVE-2020-11023 ลงในแคตตาล็อก Known Exploited Vulnerabilities เมื่อวันที่ 23 มกราคม 2025 (NVD (เปิดในแท็บใหม่))
• ไฟล์ security.txt ต้องมีฟิลด์ Contact และ Expires และต้องอยู่ที่ /.well-known/security.txt (RFC 9116 (เปิดในแท็บใหม่))

การตรวจความปลอดภัยแบบ passive คืออะไร

การตรวจแบบ passive จะอ่านเฉพาะสิ่งที่เว็บไซต์หรือ DNS ของเว็บไซต์ส่งกลับมาเมื่อมีคำขอตามปกติ

ซึ่งหมายถึงการโหลดหน้าสาธารณะ อ่านใบรับรองและส่วนหัวการตอบกลับ ดูรายการคุกกี้ที่หน้าเว็บตั้งค่าและสคริปต์ที่หน้าเว็บโหลด และค้นหาระเบียน DNS สาธารณะ การตรวจแบบ passive จะไม่เดารหัสผ่าน ไม่ส่งเพย์โหลดแบบ injection ไม่ลองเข้า URL ของหน้าผู้ดูแลระบบ และไม่สแกนพอร์ต ทุกอย่างด้านล่างทำได้ด้วยเบราว์เซอร์ curl, openssl และ dig

ตรวจสอบใบรับรอง TLS และวันหมดอายุอย่างไร

อ่านวันที่และชื่อในใบรับรองโดยตรง และตรวจสอบให้แน่ใจว่าการต่ออายุเป็นแบบอัตโนมัติ

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

ตรวจสอบว่า notAfter ยังอยู่ห่างจากวันนี้พอสมควร ใบรับรองครอบคลุมทั้ง example.com และ www.example.com หากคุณใช้ทั้งสองชื่อ (ตัวแสดงใบรับรองของเบราว์เซอร์จะแสดงรายชื่อเหล่านี้) และเบราว์เซอร์ไม่แสดงคำเตือนใด ๆ อายุของใบรับรองกำลังสั้นลงตาม Baseline Requirements ของ CA/Browser Forum (หัวข้อ 6.3.2 เวอร์ชัน 2.3.1 ณ เดือนตุลาคม 2026) ซึ่งเป็นไปตาม Ballot SC-081v3 (เปิดในแท็บใหม่) ที่ได้รับการรับรองเมื่อวันที่ 11 เมษายน 2025:

อายุที่สั้นลงทำให้การต่ออายุด้วยตนเองมีความเสี่ยง จึงควรยืนยันว่าโฮสต์หรือเครื่องมือจัดการใบรับรองของคุณต่ออายุให้อัตโนมัติ และยืนยันด้วยว่า HTTP ธรรมดาถูกเปลี่ยนเส้นทางไปยัง HTTPS:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

ผลที่ต้องการคือการตอบกลับ 301 (หรือ 308) พร้อมส่วนหัว location ที่ขึ้นต้นด้วย https://

ร้านค้าออนไลน์ควรส่งส่วนหัวความปลอดภัยใดบ้าง

ส่วนหัวการตอบกลับเพียงไม่กี่รายการช่วยป้องกันการโจมตีฝั่งเบราว์เซอร์ที่พบบ่อยได้ โดยแทบไม่มีต้นทุน

ตรวจสอบว่าร้านของคุณส่งอะไรออกมา:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

มีข้อควรระวัง 2 ข้อ ข้อแรก includeSubDomains จะบล็อกซับโดเมนใดก็ตามที่ทำงานได้เฉพาะผ่าน HTTP จึงควรตรวจสอบซับโดเมนก่อน ข้อสอง HSTS preloading กำหนดให้ max-age มีค่าอย่างน้อย 31536000 และต้องมี includeSubDomains ดังนั้นควรเพิ่ม preload เฉพาะเมื่อซับโดเมนทุกรายการพร้อมสำหรับ HTTPS แล้ว CSP แบบเต็มที่จำกัดสคริปต์เป็นสิ่งที่ควรมี แต่ OWASP ระบุว่าตั้งค่าและดูแลรักษาได้ยาก และร้านที่ใช้แอปจำนวนมากต้องทดสอบอย่างรอบคอบ

คุกกี้ของคุณตั้งค่า Secure, HttpOnly และ SameSite แล้วหรือยัง

คุกกี้ของเซสชันและตะกร้าควรมีแอตทริบิวต์ครบทั้งสามรายการ และคุณดูได้จากส่วนหัวการตอบกลับ Set-Cookie

หากไม่ได้ตั้งค่าแอตทริบิวต์ SameSite เบราว์เซอร์จะถือว่าคุกกี้นั้นเป็น Lax คุกกี้ที่สคริปต์ของคุณเองต้องอ่านจะเป็น HttpOnly ไม่ได้ จึงควรเน้นที่คุกกี้ที่ใช้ระบุตัวลูกค้าที่เข้าสู่ระบบอยู่หรือผู้ดูแลระบบ

curl -sI https://example.com/ | grep -i "^set-cookie"

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

ค้นหา mixed content ได้อย่างไร

Mixed content คือทรัพยากรใดก็ตามที่โหลดผ่าน HTTP บนหน้าที่ให้บริการผ่าน HTTPS และคอนโซลของเบราว์เซอร์จะแสดงรายการเหล่านี้

MDN (เปิดในแท็บใหม่) แบ่ง mixed content ออกเป็น 2 กลุ่ม รูปภาพ เสียง และวิดีโอเป็นประเภท “upgradable” คือเบราว์เซอร์จะขอทรัพยากรเหล่านี้ผ่าน HTTPS ให้อัตโนมัติ ส่วนสคริปต์ สไตล์ชีต iframe ฟอนต์ และคำขอ fetch() เป็นประเภท “blockable” คือเบราว์เซอร์จะบล็อก ทำให้สิ่งที่พึ่งพาทรัพยากรเหล่านั้นใช้งานไม่ได้ คำขอที่ถูกอัปเกรดซึ่งส่งไปยังที่อยู่ IP โดยตรงก็จะถูกบล็อกเช่นกัน

วิธีค้นหาคือเปิดคอนโซลในเทมเพลตหลัก (หน้าแรก คอลเลกชัน สินค้า ตะกร้า) และค้นหา http:// ในโค้ดธีม เนื้อหาของหน้า และการตั้งค่าแอป ศูนย์ช่วยเหลือของ Shopify ระบุว่าหน้าร้านใดก็ตามที่มีไฟล์ที่ไม่ได้ส่งผ่าน HTTPS จะถือว่าไม่ปลอดภัย (เปิดในแท็บใหม่) และแนะนำให้โฮสต์ไฟล์เหล่านั้นบน Shopify หรือให้บริการผ่าน HTTPS ส่วนบน WooCommerce ให้ตรวจสอบเนื้อหาโพสต์เก่าและตัวเลือกของธีม หากเว็บไซต์เคยทำงานบน http://

ตรวจหาไลบรารี JavaScript รุ่นเก่าที่มี CVE ที่ทราบกันแล้วได้อย่างไร

ทำรายการไลบรารีที่แต่ละหน้าโหลด อ่านเวอร์ชัน แล้วเปรียบเทียบกับ National Vulnerability Database

เริ่มจาก jQuery ในคอนโซลของเบราว์เซอร์ $.fn.jquery จะส่งคืนเวอร์ชันที่โหลดอยู่ (jQuery API (เปิดในแท็บใหม่)) เวอร์ชันที่ควรตั้งข้อสังเกต:

ปัญหาทั้งสองรายการของปี 2020 ได้รับการแก้ไขใน jQuery 3.5.0 การใช้เวอร์ชันที่มีช่องโหว่หมายความว่ามีโค้ดที่บกพร่องอยู่ ส่วนจะถูกโจมตีได้หรือไม่ขึ้นอยู่กับวิธีที่เว็บไซต์ส่งข้อมูลให้โค้ดนั้น WordPress มาพร้อม jQuery 3.5.1 ตั้งแต่เวอร์ชัน 5.6 (เปิดในแท็บใหม่) ดังนั้น jQuery รุ่นเก่าบนร้าน WooCommerce จึงบ่งชี้ว่า WordPress ไม่ได้อัปเดต หรือมีธีมหรือปลั๊กอินที่โหลด jQuery ชุดของตัวเอง ส่วนบน Shopify ให้ตรวจสอบไฟล์ธีมและแอปที่แทรกสคริปต์เข้ามา

security.txt คืออะไร และร้านของคุณต้องมีหรือไม่

security.txt เป็นไฟล์ข้อความธรรมดาที่บอกนักวิจัยด้านความปลอดภัยว่าจะรายงานช่องโหว่ให้คุณทราบได้อย่างไร

RFC 9116 (เปิดในแท็บใหม่) (เมษายน 2022 เป็น RFC ประเภท Informational การปฏิบัติตามจึงเป็นไปโดยสมัครใจ) ระบุว่าไฟล์ต้องให้บริการผ่าน HTTPS ที่ /.well-known/security.txt ในรูปแบบ text/plain ฟิลด์ Contact และ Expires เป็นฟิลด์ที่จำเป็น และ RFC แนะนำให้วันที่ใน Expires อยู่ห่างจากปัจจุบันไม่ถึงหนึ่งปี

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

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

DMARC ปกป้องร้านของคุณจากการปลอมแปลงอีเมลอย่างไร

DMARC ช่วยให้คุณขอให้ผู้ให้บริการกล่องจดหมายกักกันหรือปฏิเสธอีเมลที่ใช้โดเมนของคุณในที่อยู่ From โดยไม่ผ่าน SPF หรือ DKIM ที่สอดคล้องกัน

ระเบียนที่ p=none ทำได้เพียงรวบรวมรายงาน ไม่ได้หยุดอีเมลปลอมแปลง ลูกค้าคาดว่าจะได้รับอีเมลยืนยันคำสั่งซื้อและอีเมลรีเซ็ตรหัสผ่านจากโดเมนของคุณ ข้อความฟิชชิงที่แสดงโดเมนของคุณแบบตรงทุกตัวอักษรจึงควรถูกบล็อก ตรวจสอบนโยบายของคุณด้วย dig +short TXT _dmarc.example.com และดูข้อกำหนดได้ใน RFC 9989 (เปิดในแท็บใหม่) DMARC ไม่ครอบคลุมโดเมนที่หน้าตาคล้ายกัน แต่ครอบคลุมเฉพาะโดเมนที่เผยแพร่ระเบียนนั้น

Shopify จัดการอะไรให้ และคุณควบคุมอะไรบน WooCommerce

Shopify ดูแลเซิร์ฟเวอร์ที่อยู่เบื้องหลังหน้าร้าน ขณะที่ร้าน WooCommerce ที่โฮสต์เองจะปล่อยให้การตั้งค่าเซิร์ฟเวอร์เป็นหน้าที่ของคุณและโฮสต์ของคุณ

เมื่อเราตรวจสอบหน้าร้านหลายแห่งที่โฮสต์บน Shopify ในเดือนตุลาคม 2026 การตอบกลับมี HSTS ที่ max-age ประมาณ 91 วัน มี X-Content-Type-Options: nosniff และมี CSP ที่ใช้ upgrade-insecure-requests ขณะที่ frame-ancestors แตกต่างกันไปในแต่ละร้าน Shopify ระบุว่าได้รับการรับรองว่าเป็นไปตาม PCI DSS ระดับ 1 (เปิดในแท็บใหม่) ส่วนธีมและแอปที่คุณติดตั้งยังคงเป็นความรับผิดชอบของคุณ

สำหรับ WooCommerce คู่มือการเสริมความแข็งแกร่ง (hardening) (เปิดในแท็บใหม่) ของ WordPress แนะนำให้อัปเดต WordPress และปลั๊กอินอยู่เสมอ ลบปลั๊กอินที่ไม่ได้ใช้ และสอบถามโฮสต์ว่ามีมาตรการป้องกันด้านความปลอดภัยอะไรบ้าง

ทำไมการตรวจนี้จึงไม่ใช่การทดสอบเจาะระบบ

การทดสอบเจาะระบบจะพยายามโจมตีจริง ส่วนการตรวจแบบ passive ทำได้เพียงสังเกต

NIST SP 800-115 นิยามการทดสอบเจาะระบบว่าเป็นการทดสอบความปลอดภัยที่ผู้ประเมินจำลองการโจมตีในโลกจริงเพื่อหาวิธีหลบเลี่ยงฟีเจอร์ความปลอดภัยของระบบ (อภิธานศัพท์ของ NIST (เปิดในแท็บใหม่)) การตรวจแบบ passive มองไม่เห็นข้อบกพร่องฝั่งเซิร์ฟเวอร์ในปลั๊กอิน รหัสผ่านผู้ดูแลระบบที่คาดเดาง่ายหรือใช้ซ้ำ การไม่มีการยืนยันตัวตนแบบสองขั้นตอน การควบคุมสิทธิ์การเข้าถึงที่บกพร่อง หรือโค้ดที่มีช่องโหว่ซึ่งไม่ปรากฏในซอร์สของหน้า ให้ใช้การตรวจนี้เป็นพื้นฐานที่ทำซ้ำได้ทุกเมื่อ หากต้องการความมั่นใจในระดับที่ลึกกว่า ให้ว่าจ้างการทดสอบเจาะระบบที่มีขอบเขตเป็นลายลักษณ์อักษร บนระบบที่คุณเป็นเจ้าของหรือได้รับอนุญาตให้ทดสอบ

การสแกนฟรี ช่วยตรวจร้านของคุณในรอบแรก ส่วนรายงานความปลอดภัยเว็บไซต์ ครอบคลุมการตรวจแบบ passive ในบทความนี้ ตั้งแต่ TLS และการเปลี่ยนเส้นทาง ไปจนถึงส่วนหัว คุกกี้ mixed content ไลบรารีรุ่นเก่า security.txt และ DMARC พร้อมวิธีแก้ไขสำหรับผลการตรวจแต่ละรายการ เช่นเดียวกับการตรวจแบบ passive ทั่วไป รายงานนี้ไม่สามารถรับประกันได้ว่าร้านปลอดภัย

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

การตรวจความปลอดภัยแบบ passive ทำให้ร้านมีความเสี่ยงหรือไม่

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

เพิ่มส่วนหัวความปลอดภัยบน Shopify ได้หรือไม่

ส่วนหัวการตอบกลับของหน้าร้าน Shopify มาจากเซิร์ฟเวอร์ของ Shopify ดังนั้นหากไม่มีส่วนหัวที่คุณต้องการ ให้ติดต่อฝ่ายสนับสนุนของ Shopify (Shopify Support) แท็ก <meta> ของ CSP ในธีมเพิ่มคำสั่งบางรายการได้ แต่ MDN ระบุว่า frame-ancestors ไม่รองรับใน <meta>

jQuery รุ่นเก่าหมายความว่าร้านถูกแฮ็กแล้วหรือไม่

ไม่ใช่ jQuery รุ่นเก่าหมายความว่ามีการโหลดโค้ดที่มีช่องโหว่ที่ทราบกันแล้ว ซึ่งเพิ่มความเสี่ยงหากเว็บไซต์ส่ง HTML ที่ไม่น่าเชื่อถือให้เมธอดที่ได้รับผลกระทบ ให้อัปเดต jQuery หรือนำธีมหรือปลั๊กอินที่โหลด jQuery รุ่นนั้นออก

ปัจจุบันใบรับรอง TLS มีอายุใช้งานได้นานเท่าใด

ใบรับรองที่เชื่อถือได้แบบสาธารณะซึ่งออกตั้งแต่วันที่ 15 มีนาคม 2026 มีอายุใช้งานได้ไม่เกิน 200 วัน ขีดจำกัดจะลดลงเหลือ 100 วันตั้งแต่วันที่ 15 มีนาคม 2027 และ 47 วันตั้งแต่วันที่ 15 มีนาคม 2029

จำเป็นต้องมีไฟล์ security.txt หรือไม่

RFC 9116 เป็น RFC ประเภท Informational การเผยแพร่ไฟล์ security.txt จึงเป็นไปโดยสมัครใจตามมาตรฐาน ไฟล์นี้เผยแพร่ได้โดยแทบไม่มีต้นทุน และช่วยให้นักวิจัยมีช่องทางที่ชัดเจนในการติดต่อคุณ

ผลการสแกนแบบ passive ที่ไม่พบปัญหาหมายความว่าร้านปลอดภัยหรือไม่

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

แหล่งข้อมูลอ้างอิง

• Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1 (เปิดในแท็บใหม่), CA/Browser Forum, 4 ตุลาคม 2026
• Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (เปิดในแท็บใหม่), CA/Browser Forum, 11 เมษายน 2025
• Strict-Transport-Security (เปิดในแท็บใหม่), MDN Web Docs, แก้ไขล่าสุดเมื่อ 11 กันยายน 2026
• CSP: frame-ancestors (เปิดในแท็บใหม่), MDN Web Docs, แก้ไขล่าสุดเมื่อ 27 สิงหาคม 2026
• X-Content-Type-Options (เปิดในแท็บใหม่), MDN Web Docs, แก้ไขล่าสุดเมื่อ 17 มีนาคม 2026
• Using HTTP cookies (เปิดในแท็บใหม่), MDN Web Docs, แก้ไขล่าสุดเมื่อ 17 กันยายน 2026
• Mixed content (เปิดในแท็บใหม่), MDN Web Docs, แก้ไขล่าสุดเมื่อ 15 สิงหาคม 2026
• HTTP Security Response Headers Cheat Sheet (เปิดในแท็บใหม่), OWASP Cheat Sheet Series, เข้าถึงเมื่อ 22 ตุลาคม 2026
• CVE-2020-11022 (เปิดในแท็บใหม่), NIST National Vulnerability Database, เผยแพร่เมื่อ 29 เมษายน 2020
• CVE-2020-11023 (เปิดในแท็บใหม่), NIST National Vulnerability Database, เผยแพร่เมื่อ 29 เมษายน 2020
• CVE-2019-11358 (เปิดในแท็บใหม่), NIST National Vulnerability Database, เผยแพร่เมื่อ 20 เมษายน 2019
• .jquery (เปิดในแท็บใหม่), jQuery API Documentation, เข้าถึงเมื่อ 22 ตุลาคม 2026
• Updating core jQuery to version 3, part 2 (เปิดในแท็บใหม่), Make WordPress Core, 5 พฤศจิกายน 2020
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (เปิดในแท็บใหม่), IETF, เมษายน 2022
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (เปิดในแท็บใหม่), IETF, พฤษภาคม 2026
• Enabling secure connections to your Shopify store (เปิดในแท็บใหม่), Shopify Help Center, เข้าถึงเมื่อ 22 ตุลาคม 2026
• Security (เปิดในแท็บใหม่), Shopify, เข้าถึงเมื่อ 22 ตุลาคม 2026
• Hardening WordPress (เปิดในแท็บใหม่), WordPress Developer Resources, เข้าถึงเมื่อ 22 ตุลาคม 2026
• Penetration testing (glossary) (เปิดในแท็บใหม่), NIST Computer Security Resource Center, อ้างอิง NIST SP 800-115 (กันยายน 2008), เข้าถึงเมื่อ 22 ตุลาคม 2026