Security Checklist สำหรับ Vibe Coder | Vibe Coding สำหรับคนไม่ใช่โปรแกรมเมอร์ | Vibe Coding Thailand$ cat 10-security-checklist.md บทที่ 10Security Checklist สำหรับ Vibe Coder
แก่นของบทนี้
แอปที่ “ใช้ได้” ไม่ได้แปลว่า “ปลอดภัย”
Claude Code ช่วยให้คนที่ไม่ใช่ programmer สร้างเว็บ form database dashboard และ deploy ได้เร็วมาก แต่ความเร็วไม่ได้ลบความเสี่ยงด้าน security
บทนี้ไม่พยายามทำให้คุณเป็น security engineer
เป้าหมายคือให้คุณมี checklist สั้น ๆ ก่อนเปิดให้คนอื่นใช้จริง:
- อะไรห้ามทำเด็ดขาด
- อะไรต้องให้ Claude ตรวจทุกครั้ง
- red flag หน้าตาเป็นแบบไหน
- เมื่อไหร่ต้องให้คน technical ช่วย review
Security สำหรับ non-coder คือการไม่พลาดเรื่องพื้นฐานที่ทำให้ข้อมูลหลุด ระบบพัง หรือสิทธิ์เปิดกว้างเกินไป
กฎข้อแรก: อย่า blind trust
OWASP ระบุ Blind Trust เป็นความเสี่ยงสำคัญของ citizen development และ AI-assisted coding
แปลแบบง่าย ๆ:
AI สร้างให้ → app รันได้ → เราเชื่อว่าถูกและปลอดภัยแล้ว
นี่คือกับดัก
Claude ช่วยเขียน ช่วยอธิบาย และช่วย review ได้ แต่คุณต้องเป็นคนถือ checklist ไม่ใช่กด accept ทุกอย่างเพราะ “AI น่าจะรู้”
Checklist 10 ข้อก่อนเปิดให้คนอื่นใช้
Security launch gate: Green / Yellow / Red
Green / Yellow / Red: ใช้ launch gate เพื่อแยกว่าควร launch แบบจำกัด, beta/review ก่อน หรือห้าม launch
ใช้ checklist นี้ก่อน deploy จริง หรือก่อนส่ง link ให้คนอื่นกรอกข้อมูล
1. เก็บข้อมูลเท่าที่จำเป็น
Data minimization ก่อนสร้างฟอร์มข้อมูลที่ไม่เก็บ คือข้อมูลที่ไม่ต้องปกป้อง ลด field ตั้งแต่แรกจึงลด risk ได้จริง
จำเป็นต้องเก็บข้อมูลนี้จริงไหม
ตัวอย่าง waitlist อาจต้องมีแค่ email และ use case สั้น ๆ ก็พอ
อย่ารีบเก็บเบอร์โทร ที่อยู่ วันเกิด หรือข้อมูลส่วนตัวอื่น ถ้ายังไม่มีเหตุผลชัด
ข้อมูลที่ไม่เก็บ ย่อมไม่มีวันรั่วจากระบบของคุณ
ช่วย review data fields ของ app นี้
แยกเป็น 3 กลุ่ม:
1. จำเป็นต่อ feature หลัก
2. มีประโยชน์แต่ยังไม่จำเป็น
3. เสี่ยงหรือไม่ควรเก็บตอนนี้
อธิบายแบบ non-coder และอย่าเพิ่งแก้ code
2. ห้ามใส่ secret ใน code, GitHub หรือ frontend
Secret ไม่ควรไหลไปที่ไหนบ้างsecret ไม่ควรไปอยู่ใน frontend, public repo, chat, screenshot, logs หรือ URL
Secret คือข้อมูลที่ถ้าคนอื่นเห็นแล้วเอาไปใช้แทนคุณได้ เช่น API secret key, database password, service role key, webhook secret, admin token
secret ห้ามอยู่ใน GitHub
secret ห้ามอยู่ใน frontend/browser
secret ห้าม paste ลง prompt โดยไม่จำเป็น
.env
.env.local
.env.production
config file
README หรือ screenshot ที่มี key จริง
ใน repo ควรมีได้แค่ไฟล์ตัวอย่าง เช่น .env.example ที่ใช้ placeholder ไม่ใช่ค่าจริง
ช่วยตรวจ project นี้ว่ามี secret หรือ credential หลุดใน code ไหม
กติกา:
- อย่า print ค่า secret จริงซ้ำออกมา
- ถ้าเจอ ให้บอกแค่ชื่อไฟล์และชนิดของ secret
- แนะนำวิธีย้ายไป environment variable
- ตรวจว่ามี .env ถูก track ใน git หรือไม่
3. เข้าใจ Supabase key แบบสั้นที่สุด
ถ้าใช้ Supabase ให้จำเรื่องนี้ก่อน deploy:
publishable key = ใช้ใน public app ได้ แต่ยังต้องมี RLS/policy คุม data
secret key / service_role = ใช้เฉพาะฝั่ง server/backend เท่านั้น
จาก official docs ของ Supabase: secret key ให้สิทธิ์ระดับสูงกับ project data และ service role เป็น elevated key ที่ bypass RLS ได้
Claude เสนอให้ใส่ service_role key ใน frontend
Claude เสนอให้ใช้ secret key ใน client component
Claude เสนอให้ commit key จริงเพื่อให้ deploy ผ่าน
ถ้าเห็นแบบนี้ให้ถามทันที:
หยุดก่อน
key นี้เป็น publishable หรือ secret/service_role
มันจะอยู่ฝั่ง browser หรือ server
อธิบายความเสี่ยงแบบ non-coder
อย่าเพิ่งแก้ code
4. เปิด RLS และทำ policy ให้แคบ
RLS หรือ Row Level Security คือกฎว่าใครอ่าน/เขียน row ไหนได้บ้าง
เปิด RLS ก่อน
แล้วค่อย allow เฉพาะ action ที่ feature ต้องใช้
insert email ตัวเอง
select email ทุกคน
update/delete record
อ่าน dashboard leads
ช่วย review RLS และ database permissions ของ project นี้
ทำเป็นตาราง:
- table name
- user type: public / authenticated / admin
- action: select / insert / update / delete
- ควร allow หรือ deny
- เหตุผลแบบ non-coder
กติกา: อย่าเสนอปิด RLS เพื่อแก้ error
ถ้า Claude บอกว่า “ปิด RLS ก่อนเพื่อให้ใช้ได้” ให้ถือเป็น red flag สำหรับ app ที่จะเปิดจริง
Input คือสิ่งที่ user กรอก ส่ง หรือ upload เข้ามา เช่น email, name, message, URL, file, search box
อย่าคิดว่า user จะกรอกดี ๆ และอย่าคิดว่า form UI ตรวจแล้วพอ
required field ครบไหม
email เป็น email จริงไหม
ความยาวไม่เกินที่กำหนดไหม
มี field แปลก ๆ ส่งมาได้ไหม
error message เปิดเผยข้อมูลระบบเกินไปไหม
ช่วย review input validation ของ feature นี้
ตรวจทั้ง frontend และ server/API/database layer
ตอบเป็น:
1. input แต่ละตัวคืออะไร
2. ต้อง validate อะไร
3. ตอนนี้ validate ที่ไหนแล้ว
4. ยังขาดอะไร
5. test case ที่ควรลอง
อย่าเพิ่งแก้ code จนกว่าจะเสนอ plan
6. Login ไม่เท่ากับ permission
Login ไม่เท่ากับ permissionlogin บอกว่า user คือใคร แต่ permission ต้องตอบว่า user คนนั้นทำอะไรได้บ้าง
Permission ตอบว่า “คุณมีสิทธิ์ทำอะไร”
มี login แล้วไม่ได้แปลว่าปลอดภัยแล้ว
ตัวอย่าง: User A login แล้วควรเห็นข้อมูลตัวเอง แต่ไม่ควรเห็นข้อมูลของ User B
ช่วยแยก auth กับ authorization ของ app นี้
ตอบเป็นตาราง:
- role/user type
- เข้าหน้าไหนได้
- อ่านข้อมูลอะไรได้
- สร้างข้อมูลอะไรได้
- แก้/ลบอะไรได้
- enforce ตรงไหนใน code หรือ RLS
- ช่องโหว่ที่อาจเกิดขึ้น
อธิบายแบบ non-coder
ถ้า Claude แก้ permission ด้วยการใช้ admin token ทุกที่ ให้หยุดทันที
7. อย่าติดตั้ง package มั่ว
เวลา error เกิดขึ้น AI อาจเสนอให้ติดตั้ง package เพิ่ม
บางครั้งถูก แต่บางครั้งเพิ่มความเสี่ยงโดยไม่จำเป็น
ก่อนติดตั้ง ถาม 5 ข้อนี้:
จำเป็นจริงไหม
มี built-in ทำได้ไหม
package นี้น่าเชื่อถือไหม
ใช้ทำอะไรแค่ไหน
ถ้าเอาออก app ยังทำงานได้ไหม
ก่อนติดตั้ง package เพิ่ม ช่วยอธิบายว่า:
1. package นี้แก้ปัญหาอะไร
2. จำเป็นจริงไหม
3. มีทางเลือกที่ไม่ต้องเพิ่ม dependency ไหม
4. มีผลต่อ security หรือ deploy อย่างไร
5. ถ้าติดตั้งแล้ว ต้อง test อะไร
อย่าเพิ่งรัน install
สำหรับ project เล็ก ๆ หลายครั้ง code ธรรมดาดีกว่า dependency เยอะ ๆ
8. แยก local, preview, production ให้ชัด
local = เครื่องคุณ
preview = ทดสอบก่อนจริง
production = ของจริงที่ user ใช้
- environment variables
- database URL/key
- payment mode
- email provider
- test data กับ real data
Vercel ใช้ environment variables เพื่อเก็บค่าที่เปลี่ยนตาม environment และการเปลี่ยน env var มักมีผลกับ deployment ใหม่ ไม่ใช่ deployment เก่าทันที
ช่วยตรวจ deploy readiness ของ project นี้
แยก local / preview / production
ตรวจว่า:
- env var ที่จำเป็นมีอะไรบ้าง
- ค่าไหนเป็น public ได้
- ค่าไหนเป็น secret
- ค่าไหนยังเป็น test/dev value
- ต้อง redeploy หลังเปลี่ยน env var ไหม
- มี rollback plan ไหม
อย่า print ค่า secret จริง
9. Log ต้องไม่ทำข้อมูลหลุด
Log มีไว้ debug แต่ log ที่แย่ทำข้อมูลลับหลุดได้
- password
- secret key
- token
- payment info
- private customer data ที่ไม่จำเป็น
- request body ทั้งก้อนถ้ามีข้อมูล sensitive
console.log(process.env.SUPABASE_SECRET_KEY)
console.log(fullUserObject)
console.log(webhookPayload)
ช่วย review logging ใน project นี้
ตรวจว่ามี log ที่อาจเปิดเผย secret หรือข้อมูลส่วนตัวไหม
กติกา:
- อย่า print ค่า secret จริงซ้ำ
- เสนอวิธี mask/redact
- แยก log ที่ควรเก็บกับ log ที่ควรลบ
- แนะนำ error message ที่ user เห็นได้โดยไม่เผยข้อมูลระบบ
10. ปิดสิ่งที่ไม่ใช้ และรู้ว่าใครเป็นเจ้าของ
App เล็ก ๆ ก็สร้างหนี้ด้าน security ได้ โดยเฉพาะ project ที่ทำไว้แล้วลืม
ใครเป็น owner ของ project นี้
ถ้าคุณไม่ว่าง ใครเข้า Supabase/Vercel/GitHub ได้
มี key เก่าที่ไม่ใช้แล้วไหม
มี database/table/test app ที่เปิด public ทิ้งไว้ไหม
มี integration ที่ไม่ใช้แล้วไหม
มี domain หรือ deployment เก่าที่ควรปิดไหม
ช่วยทำ asset inventory สำหรับ project นี้
แยกเป็น:
- repository
- deploy platform
- database
- API keys / env vars
- third-party services
- domains
- scheduled jobs/webhooks
- owners/admins
บอกด้วยว่าอะไรควรปิด ลบ rotate หรือ review
Red flags ที่ต้องหยุดทันที
ถ้าเจอสิ่งเหล่านี้ อย่าเพิ่ง accept code:
- ปิด RLS เพื่อให้ app ใช้ได้
- secret/service_role อยู่ใน browser
- commit
.env ที่มีค่าจริง
- dashboard public อ่านข้อมูลทุกคนได้
- แก้ bug ด้วย admin permission หรือ service role ทุกที่
- เพิ่ม package เยอะเพื่อแก้ปัญหาเล็ก
- Claude อธิบายไม่ได้ว่าใครมีสิทธิ์ทำอะไร
ประโยคที่ควรใช้เมื่อเจอ red flag:
หยุดก่อน
อธิบายความเสี่ยงของวิธีนี้แบบ non-coder
มีทางเลือกที่ปลอดภัยกว่าและเปลี่ยนน้อยกว่าไหม
อย่าเพิ่งแก้ไฟล์
Security review prompt ก่อน deploy
ใช้ prompt นี้ก่อนแชร์ link จริง
ช่วยทำ security review ก่อน deploy สำหรับ project นี้
ฉันเป็น non-coder ขอให้อธิบายแบบเข้าใจง่าย
ขอบเขต:
- frontend
- API/server actions
- Supabase/database/RLS
- environment variables
- authentication/authorization
- input validation
- logging
- dependencies
- deployment settings
กติกา:
- อย่าเพิ่งแก้ไฟล์
- อย่า print secret จริง
- แยกผลเป็น Critical / High / Medium / Low
- ทุก issue ต้องมี: หลักฐาน, ความเสี่ยง, วิธีแก้ที่แนะนำ
- ถ้าไม่แน่ใจ ให้บอกว่าไม่แน่ใจ
- สรุปท้ายว่า launch ได้ไหมแบบ Green / Yellow / Red
หลังได้ report ให้แก้ Critical ก่อน แล้วค่อย High
อย่าให้ Claude แก้ทุกอย่างรวดเดียวถ้ามีหลาย issue
Green / Yellow / Red launch gate
Green — launch ได้แบบจำกัด scope
- ไม่มี secret ใน code/frontend/GitHub
- RLS เปิดและ policy แคบพอ
- public user อ่านข้อมูลคนอื่นไม่ได้
- form validate input พื้นฐานแล้ว
- env var แยก production ชัด
- มี rollback หรือวิธีปิด app ถ้าเกิดปัญหา
Yellow — launch เฉพาะ beta วงเล็ก
ใช้เมื่อ feature หลักใช้ได้ แต่ยังมี issue medium บางอย่าง และยังไม่มีข้อมูล sensitive มาก
ต้องรู้ว่าจะ monitor อะไร และมีแผนแก้ภายในเวลาสั้น ๆ
Red — ห้าม launch
- secret/service role อยู่ใน frontend
- RLS ปิดกับ table ที่มีข้อมูล user
- dashboard public เห็นข้อมูลทุกคน
- payment/login/file upload ยังไม่ได้ review
- Claude ยังอธิบาย permission model ไม่ชัด
- มีข้อมูล sensitive แต่ไม่มีคน technical review
ถ้าได้ Red อย่าให้ FOMO ชนะ checklist
เมื่อไหร่ต้องให้คนช่วย review
ให้หาคน technical ช่วย review ถ้า app มีสิ่งเหล่านี้:
- รับเงินหรือเกี่ยวข้องกับ payment
- เก็บข้อมูลส่วนตัวจำนวนมาก
- เก็บข้อมูลสุขภาพ การเงิน กฎหมาย หรือข้อมูลเด็ก
- มี login หลาย role เช่น user/admin/team
- มี file upload
- มี dashboard สำหรับข้อมูลลูกค้า
- เชื่อมต่อ system ภายในบริษัท
- ใช้ secret/admin key/server-side integration
- ถ้าพังแล้วกระทบรายได้หรือชื่อเสียงมาก
Prompt เตรียมส่งให้ reviewer:
ช่วยสร้าง security review brief ให้ human reviewer
สรุป:
- app ทำอะไร
- user types มีใครบ้าง
- data เก็บอะไร
- services ที่ใช้
- auth/permission model
- env vars/secret ที่เกี่ยวข้องโดยไม่เปิดเผยค่าจริง
- จุดที่ฉันกังวล
- คำถามที่อยากให้ reviewer ตรวจ
Security ไม่ใช่ครั้งเดียวจบ
หลัง launch แล้วให้มีรอบ review ง่าย ๆ:
ก่อน deploy ใหญ่: review checklist 10 ข้อ
ทุกเดือน: ดู key, dependency, logs, RLS, unused assets
ทุกครั้งที่เพิ่ม feature ใหม่: review data + permission ใหม่
ทุกครั้งที่ key หลุด: rotate ทันที
อย่าคิดว่า app เล็กไม่เป็นเป้า
หลายครั้ง attacker ไม่ได้เลือกคุณเพราะดัง แต่เลือกเพราะระบบ public และตั้งค่าพลาด
Prompt รวมท้ายบท
ใช้ prompt นี้เป็นด่านสุดท้ายก่อน production
ทำ final pre-launch security checklist ให้ project นี้
ฉันเป็น non-coder
ตรวจ 10 เรื่องนี้:
1. data minimization
2. secrets/env vars
3. Supabase publishable vs secret/service_role keys
4. RLS และ database policies
5. input validation
6. auth vs authorization
7. dependencies/packages
8. local/preview/production config
9. logs/error messages
10. asset ownership/lifecycle
กติกา:
- อย่าแก้ไฟล์ก่อน
- อย่า print secret จริง
- ถ้าเจอ critical issue ให้หยุดและอธิบายก่อน
- ทำ report เป็นตาราง
- ให้ launch gate เป็น Green / Yellow / Red
- เสนอ next steps ไม่เกิน 5 ข้อ
สรุป
Security สำหรับ vibe coder เริ่มจากนิสัย 5 อย่าง:
- ไม่ blind trust AI
- ไม่เก็บข้อมูลเกินจำเป็น
- ไม่ปล่อย secret หลุด
- ไม่ปิด security เพื่อให้ app ใช้ได้เร็ว
- ให้ AI อธิบาย permission เป็นภาษาคนก่อน deploy
ถ้าคุณทำแค่นี้ได้ คุณจะปลอดภัยกว่าการ vibe coding แบบกด accept ทุกอย่างมากแล้ว
บทสุดท้าย เราจะคุยเรื่องการ launch, เก็บ feedback, iterate, ใช้ PR/preview เป็น safety net และส่งต่อให้ developer เมื่อความเสี่ยงเริ่มเกินสิ่งที่ non-coder ควรแบกเอง
อัปเดตล่าสุด: 25 พ.ค. 2569
ความคิดเห็น
ยังไม่มีความคิดเห็น
เป็นคนแรกได้เลย