ความปลอดภัยของ QR Code: ความเสี่ยงของ Dynamic QR และกับดักของ URL สั้น

เผยแพร่ 2026-04-13 อ่าน 7 นาที

สรุป (TL;DR)

ไม่นานมานี้ผมสแกน QR เมนูที่คาเฟ่แห่งหนึ่ง แล้วถูกนำไปยังบริการย่อ URL แปลกๆ ชื่อ ql.st พลิกดูจึงเห็นว่ามีสติกเกอร์ใหม่แปะทับ QR เดิม เจ้าของร้านบอกว่าไม่ทราบมาหลายสัปดาห์แล้ว ช่องโหว่ที่ซับซ้อนในการ “โจมตี” QR เองนั้นหายาก เหตุการณ์จริงเกือบทั้งหมดเริ่มจากสติกเกอร์แผ่นเดียวแบบนี้

QR Code ไม่ใช่แค่ “รูปภาพ” แต่คือ ฟอร์แมตที่เข้ารหัส URL หรือข้อความเป็นภาพ ดังนั้น QR เองไม่มีฟีเจอร์ความปลอดภัย ความปลอดภัยเกือบทั้งหมดถูกกำหนดด้วย ความปลอดภัยของ URL ปลายทาง และ วิธีสร้าง QR QR แบบ static ฝัง URL อยู่ในโค้ดตรงๆ และหลังจากออกแล้วไม่สามารถเปลี่ยนเนื้อหาได้ QR แบบ dynamic เปลี่ยนเนื้อหาได้แต่ขึ้นอยู่กับ redirector server ถ้าบริการปิดตัวหรือเปลี่ยนเจ้าของ ผลการสแกนอาจเปลี่ยนเป็นหน้าอื่นไปเลย URL สั้นก็มีปัญหาหมดอายุ ถูกยึด และ tracking จึงอาจไม่เหมาะกับงานพิมพ์สาธารณะ เอกสารจัดเก็บระยะยาว หรือสื่อออฟไลน์ ค่าเริ่มต้นที่ปลอดภัยที่สุดคือ ใช้ URL static ของโดเมนตัวเองเป็น QR แบบ static ถ้าแคมเปญจำเป็นต้องมี tracking ให้ใช้ dynamic QR จาก provider ที่ไว้ใจได้ พร้อมวางแผน redirect หลังสิ้นสุดแคมเปญ ไว้ด้วย

ภูมิหลังและแนวคิด

Spec ทางการของ QR Code คือ ISO/IEC 18004 มี version 1–40 ยิ่ง version สูง module (ช่องตาราง) มากขึ้น เก็บข้อมูลได้มากขึ้น ขณะเดียวกัน QR ทุกโค้ดมี ข้อมูลแก้ไขข้อผิดพลาด (Reed-Solomon) ในปริมาณหนึ่ง มี 4 ระดับ

  • L: กู้ได้ถึงประมาณ 7% ของความเสียหาย
  • M: กู้ได้ราว 15%
  • Q: กู้ได้ราว 25%
  • H: กู้ได้ราว 30%

การเพิ่มระดับแก้ข้อผิดพลาดทำให้สแกนได้แม้สิ่งพิมพ์เปื้อนหรือถูกโลโก้ทับ แต่ ความหนาแน่น module สูงขึ้น ทำให้หากพิมพ์เล็ก กลับสแกนยากขึ้น สำหรับนามบัตรหรือโปสเตอร์ ระดับ M มักเป็นค่าเริ่มต้น และถ้าต้องวางโลโก้กลางให้พิจารณา Q·H

QR แบบ static เก็บ URL ตรงลงใน module ทำให้ผลการสแกนถาวร QR แบบ dynamic เก็บ “URL redirect สั้น” และ provider สามารถเปลี่ยนปลายทางได้ สะดวก แต่ความยืดหยุ่นนั้นคือต้นตอของความเสี่ยงระยะยาว

เปรียบเทียบและข้อมูล

เกณฑ์Static QRDynamic QR
URL ที่เข้ารหัสURL ปลายทางตรงๆURL สั้นของ redirector
Tracking การสแกน (รวบรวมสถิติ)โดยทั่วไปไม่ได้มีให้โดยปริยาย
ความเสี่ยงหมดอายุไม่มีตราบที่ยังถือโดเมนขึ้นอยู่กับสัญญา·แผน·การปิดกิจการของ provider
ขึ้นอยู่กับบุคคลที่สามไม่มีredirector provider
Surface ของ phishingตรวจสอบ URL ปลายทางเพียงอย่างเดียวถ้า redirector ถูก hack หรือเปลี่ยนเจ้าของ ปลายทางเปลี่ยนได้
แก้ไขได้ไม่ (ต้องออกใหม่)ได้ (ยืดหยุ่น)

ข้อดี “URL สั้นดูสะอาด” กลายเป็นข้อเสีย เพราะคนตรวจสอบ URL ด้วยสายตาไม่ได้

สถานการณ์จริง

สถานการณ์ 1 — สิ่งพิมพ์ออฟไลน์เช่นนามบัตร·โปสเตอร์ เมื่อเร็วๆ นี้ผมหยิบนามบัตรของตัวเองปี 2019 ขึ้นมาอีกครั้ง ลิงก์ bit.ly บนนั้นพ่น 404 แล้ว ดูเหมือนสัญญาบริการ tracking ตอนนั้นสิ้นสุดไป การเข้ารหัส URL canonical ของโดเมนตัวเอง เป็น QR static เป็นตัวเลือกที่คงทนที่สุด ยิ่งพิมพ์เล็กยิ่งควรลดระดับแก้ข้อผิดพลาดและจำนวน module ให้น้อยสุดเพื่อเพิ่มอัตราการสแกนได้

สถานการณ์ 2 — การวัดผลแคมเปญการตลาด สตาร์ทอัพหนึ่งใช้ dynamic QR ที่บูธงาน 3 เดือนต่อมา บริการนั้นเปลี่ยนฟีเจอร์ฟรีเป็นเสียเงิน ทำให้ redirect ไปหน้า “แผน expired” ผมใช้ path บนโดเมนของตัวเองแบบ yourdomain.com/go/summer-2026 + UTM ถ้าเป็นไปได้ เพราะตราบที่ถือโดเมนอยู่ก็ไม่มีวันหมดอายุ

สถานการณ์ 3 — ความสมบูรณ์·การตรวจสอบเอกสาร แทนที่จะใส่ URL ใน QR ให้ใส่ hash ของเอกสาร หรือ URL parameter ที่เซ็นแล้ว (?d=abc123&sig=...) เพื่อให้หลังสแกนตรวจสอบความตรงกับต้นฉบับได้ ในโปรเจ็กต์ใบรับรองหนึ่ง ผมใส่ SHA-256 16 ตัวแรก + HMAC signature ทำให้ QR version ขึ้นไปถึง 10+ ต้องบาลานซ์กับขนาดพิมพ์อีกครั้ง การประยุกต์กับสัญญา·ใบรับรอง·ฉลากผลิตภัณฑ์ช่วยตรวจจับการปลอมแปลงได้

ความเข้าใจผิดที่พบบ่อย

“QR เองถูก hack ได้” QR เป็นเพียง spec การเข้ารหัสข้อมูล การโจมตีที่ “เจาะ QR” โดยตรงหายาก ความเสี่ยงจริงคือ URL ใน QR เป็นเส้นทาง phishing·malware หรือ การปลอมแปลงทางกายภาพด้วยการแปะสติกเกอร์ทับ QR เดิม QR ในพื้นที่สาธารณะ ควรตรวจสอบด้วยสายตาว่ามีสติกเกอร์ทับหรือไม่เป็นเรื่องพื้นฐาน

“URL สั้นสะอาดกว่าก็ดีกว่า” ทางสายตาใช่ แต่ผู้ใช้ตรวจสอบ URL ไม่ได้ และถ้าบริการย่อถูกปิด·ขาย·hack ผลลัพธ์ของสิ่งพิมพ์ทั้งหมดเปลี่ยน ยิ่งเป็นของที่จัดเก็บระยะยาว URL ยาวของโดเมนตัวเองยิ่งปลอดภัย

“H ระดับแก้ข้อผิดพลาดดีสุดเสมอ” ระดับ H มีประโยชน์สำหรับการวางโลโก้ แต่จำนวน module เพิ่ม สำหรับขนาดพิมพ์เล็ก อัตราการจดจำกลับลดลง สำหรับนามบัตรขนาดเล็ก M มักเป็นค่าเริ่มต้น

“สแกน QR แล้วรู้ปลายทางได้เลย” กล้องในตัวของ iOS 17·18 แสดงแบนเนอร์ URL แต่กล้อง OEM ของ Android บางรุ่นและ third-party scanner เปิดเบราว์เซอร์ทันทีแค่แตะครั้งเดียว phishing ที่ปลอมเป็น QR login Wi-Fi สาธารณะก็พุ่งเป้าที่การเปิดอัตโนมัติแบบนี้ ให้ ปิด auto-open และสร้างนิสัยตรวจสอบโดเมนหลังสแกนจะปลอดภัยกว่า

เช็กลิสต์

  1. อายุการใช้งานนานแค่ไหน
    • หลายปี → static QR + URL โดเมนตัวเอง
    • แคมเปญสั้น → dynamic QR หรือ UTM parameter
  2. จำเป็นต้อง track หรือไม่
    • ไม่ → static QR พอ
    • ใช่ → dynamic QR จาก provider ที่ไว้ใจได้ ต้องการแผน redirect สำรอง
  3. ขนาดพิมพ์
    • เล็กมาก → ลดปริมาณข้อมูล ตั้ง error correction ประมาณ M
    • กลาง–ใหญ่ → ถ้าต้องการใส่โลโก้ เลือก Q·H
  4. ติดในพื้นที่สาธารณะหรือไม่
    • ใช่ → ตรวจสอบเป็นประจำว่ามีสติกเกอร์ทับหรือไม่
  5. URL ปลายทางปลอดภัยไหม
    • ตรวจสอบ HTTPS โดเมนตัวเอง และว่าใช้งานได้อยู่ปัจจุบัน
  6. สร้างที่ไหน
    • ถ้าเป็นไปได้เลือก สร้างในเบราว์เซอร์·ออฟไลน์ เพื่อไม่ให้ URL ที่ใส่ไปเหลือใน log ของเซิร์ฟเวอร์ภายนอก

เครื่องมือที่เกี่ยวข้อง

เครื่องสร้าง QR Code ของ Patrache Studio สร้าง QR ภายในเบราว์เซอร์ จึงไม่มีการส่ง URL ที่ป้อนไปยังเซิร์ฟเวอร์ภายนอก หากวางแผนอัปโหลดรูปที่มี QR ไปบนเว็บ ให้ปรับเกณฑ์การเลือกฟอร์แมตที่ คู่มือการบีบอัดรูปภาพฉบับสมบูรณ์ และหากต้องแทรก QR เข้าสู่เอกสารเพื่อส่ง workflow ตาม ข้อดีด้านความปลอดภัยของการรวม·แบ่ง PDF ในเบราว์เซอร์ จะช่วยรักษา privacy boundary ที่สอดคล้องกัน

อ้างอิง

เครื่องมือที่เกี่ยวข้อง

tools.patrache.studio/qr/generator/