2 min read

Personal Security ในยุค Vibe Coding: เอาตัวรอดยังไงเมื่อใครๆ ก็เขียนแอปได้

Personal Security ในยุค Vibe Coding: เอาตัวรอดยังไงเมื่อใครๆ ก็เขียนแอปได้
Photo by Philipp Katzenberger / Unsplash

ยุคที่ทุกคนเป็น Developer

"Vibe Coding" คือคำที่ Andrej Karpathy ใช้เรียกการเขียนโค้ดด้วยการคุยกับ AI โดยไม่ต้องเข้าใจโค้ดจริงๆ เพียงแค่บอก "vibe" ว่าอยากได้อะไร แล้ว AI จะสร้างให้ ผลลัพธ์คือทุกวันนี้ใครๆ ก็สร้าง SaaS, mobile app, หรือ web service ขึ้นมาได้ภายในไม่กี่ชั่วโมง โดยที่ไม่ต้องผ่าน CS101 หรือเข้าใจ HTTP ด้วยซ้ำ


ในมุมของคนที่ทำงานสาย Web Development และ Cybersecurity มาหลายปี ผมมองว่ายุคนี้คือดาบสองคม ดาบหนึ่งคือ Democratization ของการสร้างสรรค์ ซึ่งเป็นเรื่องดี อีกข้างหนึ่งที่น่ากังวลคือ มีบริการเกิดใหม่จำนวนมหาศาลที่สร้างขึ้นโดยคนที่อาจไม่เคยรู้จัก OWASP Top 10, ไม่เคยได้ยินคำว่า rate limiting, หรือไม่เข้าใจว่า bcrypt ต่างจาก MD5 ยังไง


ปัญหาคือ AI มันเขียนโค้ดที่ "ใช้งานได้" ให้คุณได้ แต่ไม่การันตีว่า "ปลอดภัย" และเจ้าของแอปหลายคนก็ไม่ได้ตรวจสอบ เพราะตอนเขาทดสอบ มันก็ใช้งานได้นี่นา ลูกค้าก็ใช้ได้ เงินก็เข้า แค่นี้ก็เพียงพอแล้วในมุมของเขา


ในฐานะผู้ใช้ เราจึงต้องดูแลตัวเองมากขึ้น บทความนี้จะแนะนำ 5 หลักการสำคัญที่คุณควรทำในยุค Vibe Coding

ใช้ Password Manager

เพราะเราไม่มีทางรู้ว่าเขาเก็บรหัสผ่านยังไง นี่คือเรื่องพื้นฐานแต่สำคัญที่สุด
ตามหลักทุกเว็บควรเก็บรหัสผ่านด้วย bcrypt หรือscrypt ที่มี salt เป็นของแต่ละ user แต่ในความเป็นจริง...

  • บางที่ใช้ MD5 หรือ SHA-1 (ซึ่งแตกได้ในระดับวินาทีด้วย rainbow table)
  • บางที่ใช้ hashing แต่ลืมใส่ salt ทำให้ผู้ใช้ที่รหัสเหมือนกันมี hash เหมือนกัน
  • บางที่ใช้ encrypt แทนการ hash (ถ้า key รั่วก็ถอดได้หมด)
  • บางที่... เก็บเป็น plain text จริงๆ

แม้แต่บริษัทใหญ่ก็เคยพลาด LinkedIn รั่ว 117 ล้านบัญชีปี 2012, Adobe รั่ว 153 ล้านบัญชีปี 2013, RockYou รั่วแบบ plaintext ปี 2009 รหัสผ่านเหล่านี้ถูกเอาไปทำ wordlist ที่แฮกเกอร์ทั่วโลกใช้กันถึงทุกวันนี้ ลองเอาอีเมลตัวเองไปเช็คที่ haveibeenpwned.com ดูเล่นๆ ก็ได้ โอกาสสูงมากที่จะเจอ แล้วถ้าคุณใช้รหัสเดียวกันทุกที่ล่ะ?
นี่คือ การโจมตี ที่เรียกว่า Credential Stuffing แฮกเกอร์เอารหัสที่หลุดจากเว็บ A ไปลองล็อกอินกับเว็บ B, C, D ด้วยอีเมลเดียวกัน อัตราสำเร็จต่ำๆ แค่ 0.1% ก็พอที่จะทำกำไรอาชญากรรมไซเบอร์ได้สบาย เพราะข้อมูลที่ลีคออกมามีหลักร้อยล้านบัญชี

สิ่งที่ควรทำ:

ใช้ Password Manager เช่น, 1Password, หรือ KeePass (offline)
รหัสผ่านควรยาว 16+ ตัวอักษร สุ่มทุกตัว ไม่ต้องจำ ไม่ต้องคิดเอง
ใช้รหัสไม่ซ้ำกันทุกบัญชี
เปิด 2FA ทุกที่ที่รองรับ / ใช้ TOTP (Authy, Google Authenticator) หรือ hardware key (YubiKey) จะดีกว่า SMS เพราะพวก SIM swap attack มีจริง
Master password ของ Password Manager ต้องแข็งแรงและจำได้ ใช้ passphrase 5-6 คำสุ่มจะดีกว่ารหัสซับซ้อนสั้นๆ

ถ้าคุณยังจดรหัสบน Notes แอป หรือใช้ "Password123!" หลายเว็บ ก็ถือว่าโชคยังดีมากในยุคนี้ถ้ายังไม่โดนแฮค

ระวังการให้สิทธิ์ OAuth, Google Login, SSO

"Sign in with Google" สะดวก คลิกเดียวจบ ไม่ต้องจำรหัส ไม่ต้องสมัคร แต่ในเบื้องหลังคุณกำลังให้กุญแจกับใครบางคน

OAuth 2.0 ทำงานโดยการให้ third-party app ได้รับ Access Token ที่อนุญาตให้เข้าถึง resource ของคุณตาม scope ที่กำหนด ปัญหาคือคนส่วนใหญ่กดยอมโดยไม่อ่านว่า scope คืออะไร และที่แย่กว่านั้นคือ Vibe coder บางคนก็ขอ scope แบบกว้างๆ ไว้ก่อน เพราะไม่รู้ว่าจริงๆ ต้องการแค่ไหน "ขอไปก่อน เผื่อใช้"

Scope ที่อันตรายและเจอบ่อย:

  • gmail.readonly หรือ gmail.modify อ่าน/แก้ไขอีเมลคุณได้หมด
  • drive เข้าถึงไฟล์ใน Drive ทุกไฟล์ ไม่ใช่แค่ที่คุณเลือก
  • contacts ดึง contact list ทั้งหมดของคุณ
  • calendar อ่านและสร้างนัดหมาย เห็นว่าคุณนัดใครเมื่อไรที่ไหน
  • userinfo.profile + email อันนี้ขั้นต่ำ ก็ควรให้แค่นี้ถ้าไม่ได้ทำอะไรมากกว่านี้

ถ้าแอปเหล่านี้สร้างโดย vibe coder ที่เก็บ token ไว้ใน database ที่ไม่ปลอดภัย หรือ log token ไว้ใน CloudWatch/log file แบบไม่ได้คิด แล้ว token คุณรั่ว = บัญชี Google คุณโดนเข้าถึงโดยไม่ต้องรู้รหัสผ่าน และที่น่ากลัวคือ refresh token อยู่ได้นาน หลายเดือนถึงปี

Worst case scenarios จากของจริง:

  • App เก็บ refresh token ไว้แบบไม่ได้เข้ารหัส แล้ว database โดน SQL injection
  • App มี SSRF/RCE bug ทำให้ attacker ดึง token ออกได้ทั้งระบบ
  • เจ้าของ app ขายข้อมูลให้บริษัทอื่น (เคยเกิดกับ extension Chrome หลายตัว)
  • Service ปิดตัว แต่ token ยังใช้ได้อยู่หลายปีเพราะไม่ได้ revoke
  • Phishing site ทำหน้า OAuth consent ปลอม

สิ่งที่ควรทำ:

เข้าไปตรวจสอบ Third-party access เช่น myaccount.google.com/permissions (Google), account.microsoft.com (Microsoft) เป็นประจำ ทุก 3-6 เดือน
ถอนสิทธิ์ (revoke) แอปที่ไม่ได้ใช้แล้ว ซึ่งส่วนใหญ่จะมีรายการเยอะกว่าที่คิด

ก่อนกดยอม อ่าน scope ทุกครั้ง ถ้า "เครื่องมือแปลงไฟล์ PDF" ขอสิทธิ์อ่าน Gmail นั่นคือธงแดง สำหรับงานสำคัญ พิจารณาใช้ Sign in with Apple จะดีกว่า มี email relay ที่ปกปิดอีเมลจริงได้ และสามารถปิดการเข้าถึงได้ทีหลัง


ถ้า service สำคัญ พิจารณาใช้ separate Google account แยกต่างหาก ไม่ผูกกับบัญชีหลักที่มีข้อมูลส่วนตัว

ระวัง phishing ตรวจสอบ URL ของหน้า OAuth ว่าเป็น accounts.google.com จริง ไม่ใช่เว็บปลอม

ระวังข้อมูลส่วนตัวที่กรอกในระบบ

ทุก form ที่คุณกรอก คือข้อมูลที่อาจรั่วได้ในมุม developer การเก็บข้อมูลให้ปลอดภัยต้องมีหลายชั้น:

  • Encryption at rest (database encrypted)
  • Encryption in transit (HTTPS, TLS 1.3)
  • PII tokenization สำหรับข้อมูลสำคัญๆ
  • Access control แบบ least privilege
  • Audit log ทุกการเข้าถึง
  • PDPA/GDPR compliance

แต่จากที่เห็นมา vibe-coded apps ส่วนใหญ่... ไม่ได้ทำเลยสักข้อ
ตัวอย่าง classic คือ Firebase ที่ rules เขียนว่า allow read, write: if true; แปลว่าใครก็เข้าถึงข้อมูลใน database ได้หมด เคยมี security researcher สแกนเจอ Firebase ที่เปิดเผยข้อมูลผู้ใช้นับล้านบัญชี และ S3 bucket ที่ misconfigured ก็เป็น breach pattern ที่เจอแทบทุกเดือน เช่น Capital One รั่ว 100 ล้านบัญชีปี 2019 ก็เพราะเรื่องนี้


อีกเรื่องที่คนไม่ค่อยคิด บริการที่ใช้ AI provider เช่น OpenAI API หรือ Claude API ในเบื้องหลัง ข้อมูลที่คุณกรอกอาจถูกส่งไป Third-party นั้นด้วย ขึ้นกับว่าเขาตั้ง data retention/training policy ไว้ยังไง

ข้อมูลที่ควรระวังเป็นพิเศษ:

  • เลขบัตรประชาชน, passport, ใบขับขี่
  • ที่อยู่จริง, เบอร์โทรศัพท์
  • หมายเลขบัตรเครดิต / ข้อมูลธนาคาร
  • ข้อมูลสุขภาพ
  • ภาพถ่ายที่มี face data หรือ biometric
  • ข้อมูลที่อยู่ของลูก/ครอบครัว
  • Geolocation ที่ละเอียด

สิ่งที่ควรทำ:

  • ให้ข้อมูลแค่ที่จำเป็น ถ้าเว็บขนมขอเลขบัตรประชาชน นั่นไม่ปกติ
  • ใช้ disposable email สำหรับสมัครบริการที่ไม่แน่ใจ เช่น SimpleLogin, AnonAddy, หรือ Gmail+alias (yourname+AA@gmail.com)
  • ใช้ virtual credit card สำหรับซื้อของออนไลน์ หลายแบงค์มีฟีเจอร์ออกบัตรเสมือนแบบจำกัดวงเงิน
  • ใช้เบอร์ที่สอง ถ้าทำได้ อย่าใช้เบอร์หลัก
  • อย่าอัพโหลดบัตรประชาชนหรือ KYC documents ให้บริการที่คุณไม่รู้จักเจ้าของ โดยเฉพาะ "AI photo enhancer" หรือ "ID verification" ที่ผุดเป็นดอกเห็ด
  • ระวัง form ที่ขอ permission พิเศษบน mobile location, contacts, camera ที่ไม่จำเป็นกับการใช้งาน

อ่าน Privacy Policy / Terms of Use แม้จะรู้ว่ามันถูก Gen มา

ผมรู้ว่ามันน่าเบื่อ ผมรู้ว่าทุกคนกด "I Agree" โดยไม่อ่าน รวมถึงตัวผมเองในหลายๆ กรณี
แต่ในยุค Vibe Coding Privacy Policy อาจถูก Gen ด้วย ChatGPT ภายใน 30 วินาที โดยที่เจ้าของแอปไม่ได้อ่านเองด้วยซ้ำ บางทีเอกสารบอกอย่างหนึ่ง แต่โค้ดทำอีกอย่าง ยิ่งน่ากลัว เพราะคุณคิดว่าเขาทำตามที่เขียน แต่จริงๆ เขาไม่ได้สนใจ

ที่ควรดูจริงๆ ไม่ใช่อ่านทั้งหมด แต่ scan หาจุดสำคัญในเวลา 1-2 นาที Red flags ที่ควรเตือนใจ:

  • ไม่มีชื่อบริษัทผู้ให้บริการชัดเจน หรือมีแต่ชื่อบุคคลทั่วไป
  • ไม่มีที่อยู่ติดต่อ ไม่มีอีเมล privacy officer / DPO
  • ใช้ template generic เช่น "We may share your data with our partners" โดยไม่ระบุว่าใคร
  • อ้างกฎหมายผิดประเทศ (เช่น เว็บไทยอ้าง California Privacy Act เฉยๆ)
  • ระบุว่าข้อมูลอาจถูกขายต่อ (sold/shared/transferred to third parties)
  • ข้อมูลถูกเก็บ "indefinitely" หรือไม่มีกำหนดลบ
  • Data center อยู่ในประเทศที่ไม่มี data protection law ที่ชัดเจน
    ข้อความขัดแย้งกันเองระหว่างหลาย section (สัญญาณว่า AI gen แล้วไม่ได้ตรวจ)
  • เปลี่ยนแปลงนโยบายได้โดยไม่ต้องแจ้ง

Green flags ที่ดูน่าเชื่อถือ:

  • ระบุชื่อนิติบุคคล + เลขทะเบียน + ที่อยู่
  • มี DPO (Data Protection Officer) และอีเมล์ติดต่อ
  • ระบุ data retention period ชัดเจน เช่น "เก็บไว้ 12 เดือนหลังบัญชีถูกลบ"
  • มีกระบวนการ data subject rights (ขอดู, ขอลบ, ขอแก้ไข) ที่เป็นรูปธรรม
  • มี security disclosure policy หรือ bug bounty program
  • มีประวัติ company หรือ team ที่ตรวจสอบได้ LinkedIn, GitHub, Twitter

สิ่งที่ควรทำ:

  • เช็ค WHOIS ของ domain ถ้า private registration ทั้งหมดและเพิ่งสร้างไม่กี่เดือน ระวัง
  • เสิร์ชชื่อเจ้าของ/บริษัท มีตัวตนจริงไหม มี LinkedIn ไหม มี press coverage ไหม
  • ดู review จากแหล่งหลายที่ ไม่ใช่แค่ landing page ของเขา
  • ถ้าเป็นบริการที่ต้องใช้ข้อมูลสำคัญ เลือกผู้ให้บริการที่ผ่าน SOC 2, ISO 27001, หรือมี PDPA/GDPR certification
  • ถ้าเป็น mobile app เช็ค permission ที่ขอใน app store ก่อนติดตั้ง

Backup เพราะเราไม่รู้ว่าจะล่มเมื่อไร


ในยุคที่ใครๆ ก็สร้าง SaaS ได้ ปัญหาคือ... ใครๆ ก็ปิดได้เช่นกัน

เหตุผลที่บริการอาจหายไปกะทันหัน:

  • เจ้าของหมดเงิน ไม่ต่อ AWS/Vercel/Supabase
  • เจ้าของเบื่อ ไปทำโปรเจกต์ใหม่
  • โดน DDoS หรือ hack แล้วไม่มี Disaster Recovery plan
  • ติดคดี ถูกระงับโดเมน หรือลืมต่ออายุโดเมน
  • โดน acquisition แล้วบริการเดิมถูกปิด (acqui-hire)
  • เจ้าของหายตัวไปจริงๆ (เกิดบ่อยกว่าที่คิด)

แม้บริการใหญ่ๆ ก็เคยปิดมาแล้ว Google Reader, Google+, Inbox, Vine, Wunderlist, Atom (GitHub), Picasa ฯลฯ ไม่ต้องพูดถึง startup เล็กๆ ที่หายไปไม่มีคำเตือน Killed by Google มี list ยาวเหยียดให้ดู


ที่หนักกว่าคือ บางครั้งคุณ "เข้าได้" แต่ "export ไม่ได้" ข้อมูลของคุณติดอยู่ในระบบเขา แบบนี้เรียกว่า data lock-in และเป็นปัญหาใหญ่กับบริการ note-taking, project management, AI assistants หลายเจ้า


สิ่งที่ควรทำ:

  • ใช้ 3-2-1 Backup Rule: มีข้อมูล 3 copies, ใน 2 ประเภท media ที่ต่างกัน, อย่างน้อย 1 copy เก็บนอกสถานที่ (offsite/cloud)
  • Export ข้อมูลสำคัญเป็น standard format เช่น CSV, JSON, Markdown, PDF ไม่ใช่ proprietary format ที่ต้องใช้แอปเขาเปิดเท่านั้น
  • ใช้ Google Takeout, Apple Privacy Portal, Facebook Download Your Information เพื่อดาวน์โหลดข้อมูลตัวเอง (ทำทุก 6 เดือน)
  • สำหรับงานสำคัญ เก็บ local copy ใน external HDD/SSD + cloud backup (Backblaze, S3 ใดๆ)
  • เอกสารสำคัญ scan เก็บไว้ด้วย และเก็บ original ในที่ปลอดภัย
  • ทดสอบ restore เป็นระยะ หลายคน backup สม่ำเสมอแต่ไม่เคยลอง restore แล้วมารู้ตอนต้องการใช้ว่าไฟล์เสีย หรือ password ที่ใช้เข้ารหัส backup จำไม่ได้ (พวก Blockchain Hardware Wallet นี่คือตัวอย่างที่ดี บางคนลืม Seed Phase)
    ใช้ version control (Git) สำหรับงานเขียน, code, config files, dotfiles
  • สำหรับ note-taking ใช้บริการที่ export เป็น markdown ได้ เช่น Obsidian (local-first) แทน proprietary format

ผมเคยเห็นคนเสียงาน 2 ปีเพราะ note-taking app ปิดตัวกะทันหัน และเพิ่งรู้ว่า "export feature" ที่เขาเคยมั่นใจ มันส่งออกแค่ title กับวันที่ เนื้อหาทั้งหมดติดอยู่ใน server ที่ไม่มีอยู่อีกต่อไปแล้ว

อยากชวนทุกคนเป็น Security Guardian ของตัวเอง


Vibe Coding จะอยู่กับเราต่อไปเรื่อยๆ และจะมีบริการใหม่ๆ ผุดขึ้นมาในอัตราที่เร็วกว่าใครจะตามทัน บางอันดี บางอันเป็นภัย และบางอันเป็นภัยทั้งที่เจ้าของก็ไม่รู้ตัว
หลักง่ายๆ ที่อยากฝากไว้:

Don't trust. Verify.

สรุปสั้นๆ

  1. Password Manager + 2FA = พื้นฐานที่ต่อรองไม่ได้
  2. ตรวจสอบ OAuth permissions ทุก 3-6 เดือน ถอนสิทธิ์ที่ไม่ใช้
  3. Minimal data sharing ให้น้อยที่สุดเท่าที่บริการจะใช้งานได้
  4. อ่าน Privacy Policy แบบ scan หา red flags
  5. Backup 3-2-1 ทุกอย่างที่สำคัญ และทดสอบ restore สม่ำเสมอ

ในยุคที่ AI ทำให้สร้างของได้ง่ายขึ้น 10 เท่า Surface ของความเสี่ยงด้าน security ก็ขยายขึ้น 10 เท่าเช่นกัน คนที่จะอยู่รอดในยุคนี้ ไม่ใช่คนที่เก่งที่สุด แต่คือคนที่ระมัดระวังที่สุด
เพราะสุดท้ายแล้ว ไม่ว่าใครจะเขียนแอปขึ้นมา คนที่ต้องรับผลกระทบเมื่อเรื่องผิดพลาด คือคุณ


Stay safe out there.