เช็คลิสต์ความปลอดภัยของ Claude Code สำหรับการตรวจจุดเว็บแอปแบบด่วน

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

การตรวจความปลอดภัยแบบสั้นเป็นการทบทวนอย่างรวดเร็ว (มัก 30–60 นาที) ที่ตั้งใจจับปัญหาเด่นชัดและมีผลกระทบสูงก่อนส่งขึ้นโปรดักชัน มันไม่ใช่การตรวจสอบเต็มรูปแบบ คิดว่ามันเหมือนการเดินตรวจความปลอดภัย: สแกนเส้นทางที่มักล้มเหลวในแอปจริงแล้วหาหลักฐาน ไม่ใช่การเดา

เช็คลิสต์ความปลอดภัยของ Claude Code ฉบับนี้โฟกัสที่ส่วนที่มักพังบ่อยในเว็บแอปทั่วไป:

• สมมติฐานการยืนยันตัวตน (คุณรู้ได้อย่างไรว่าเป็นผู้ใช้คนไหน)
• ช่องว่างการอนุญาต (พวกเขาทำอะไรได้บ้าง)
• การตรวจรับค่าเข้า
• การจัดการความลับ
• พื้นผิวการฉีดที่พบบ่อย (SQL, การรันคำสั่ง, การเรนเดอร์เทมเพลต, การเปลี่ยนเส้นทาง, การอัปโหลด)

มันไม่ได้พยายามพิสูจน์ว่าไม่มีบั๊ก, วิเคราะห์ผู้คุกคามเชิงซับซ้อน, หรือตัดสินใจแทนการทดสอบเชิงบุกรุก

"ข้อค้นพบเชิงรูปธรรม" หมายความว่าทุกปัญหาที่บันทึกมีหลักฐานที่นักพัฒนาสามารถทำงานต่อได้ทันที สำหรับแต่ละข้อค้นพบ จด:

• ไฟล์และชื่อฟังก์ชัน/ฮэндเลอร์ที่แน่นอน
• พฤติกรรมเสี่ยงสั้น ๆ
• ขั้นตอนรีโปรที่น้อยที่สุด (คำขอ, เพย์โหลด, หรือเส้นทางการคลิก)
• ทำไมมันถึงสำคัญ (ผลกระทบ) และใครสามารถเรียกใช้มันได้
• แนวทางแก้ที่ปลอดภัย (ไม่ต้องเขียนใหม่ทั้งหมด)

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

ตั้งขอบเขตใน 10 นาที

การตรวจแบบด่วนจะได้ผลถ้าคุณจำกัดเป้าหมาย ก่อนขอให้ Claude Code ดูอะไรก็ตาม ให้ตัดสินใจก่อนว่าคุณพยายามพิสูจน์อะไรวันนี้ และสิ่งใดคุณจะไม่ตรวจ

เริ่มจาก 1–3 เส้นทางผู้ใช้จริงที่ความผิดพลาดมีค่าเสียหาย เช่น เกิดค่าใช้จ่าย รั่วข้อมูล หรือให้สิทธิ์มากเกินไป ตัวอย่างที่ดีคือหน้าล็อกอิน การรีเซ็ตรหัสผ่าน ชำระเงิน และหน้าจอแก้ไขของแอดมิน

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

แล้วเขียนสมมติฐานภัยคุกคามด้วยคำง่าย ๆ คุณกำลังป้องกันผู้ใช้ที่แค่คลิกเล่น ผู้โจมตีภายนอกที่ใช้สคริปต์ หรือคนภายในที่มีสิทธิ์บ้าง? คำตอบเปลี่ยนว่า "พอรับได้" เป็นแบบไหน

สุดท้าย กำหนดเกณฑ์ผ่านและไม่ผ่านเพื่อให้การตรวจจบด้วยข้อค้นพบ ไม่ใช่ความรู้สึก กฎง่าย ๆ ใช้งานได้ดี:

• ผ่าน: ทุกการกระทำที่มีความสำคัญต้องมีการตรวจ authn และ authz ที่ชัดเจน
• ไม่ผ่าน: จุดสิ้นสุดใด ๆ เชื่อใจไคลเอนต์ในเรื่อง user ID หรือ role
• ผ่าน: การรับค่าถูกตรวจฝั่งเซิร์ฟเวอร์ ไม่ใช่แค่ UI
• ไม่ผ่าน: ความลับปรากฏในบันทึก คอนฟิก หรือโค้ดฝั่งไคลเอนต์

ถ้าคุณบอกลักษณะความล้มเหลวไม่ได้ ขอบเขตยังไม่ชัดพอ

เตรียมบริบทที่จะให้ Claude Code

การตรวจจะได้ผลถ้ารุ่นดูตรงจุดที่ถูกต้อง รวบรวมชุดโค้ดและบันทึกเล็ก ๆ เพื่อให้การทบทวนออกมาเป็นหลักฐาน ไม่ใช่การเดา

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

ชุดที่ใช้งานได้จริงมักประกอบด้วย:

• จุดเข้า auth: การแยกวิเคราะห์ session/JWT, การตั้งค่า cookie, callback ของล็อกอิน, มิดเดิลแวร์ auth
• เส้นทาง + ฮैंडเลอร์: คอนโทรลเลอร์, เมธอด RPC, ตัวแก้ GraphQL, ฮนด์เลอร์งานแบ็คกราวด์
• เลเยอร์ข้อมูล: คำสั่ง ORM, ฮีลเปอร์ SQL ดิบ, บิลเดอร์คิวรี, มิเกรชันสำหรับตารางสำคัญ
• การเช็กนโยบาย: การตรวจบทบาท, การเช็กเจ้าของ, ฟีเจอร์แฟลก, จุดสิ้นสุดเฉพาะแอดมิน
• การตรวจรับค่า: ตัวตรวจสคีมาคำขอ, ฮนด์เลอร์อัปโหลดไฟล์, โค้ดการดีซีเรียไรซ์

เพิ่มบันทึกสภาพแวดล้อมสั้น ๆ ให้สมมติฐานชัดเจน: session vs JWT, โทเค็นอยู่ที่ไหน (cookie หรือ header), พฤติกรรม reverse proxy หรือ API gateway, คิว/งาน cron, และจุดสิ้นสุดที่ "เฉพาะภายใน" ใด ๆ

ก่อนไล่หาบั๊ก ให้ขอ inventory: จุดเข้า, จุดสิ้นสุดกับสิทธิพิเศษ, และคลังข้อมูลที่ถูกแตะต้อง เพื่อป้องกันการพลาดพื้นผิว

ตกลงรูปแบบผลลัพธ์ด้วยว่าจะบังคับเป็นข้อค้นพบเชิงรูปธรรม ตารางง่าย ๆ ทำงานได้ดี: ข้อค้นพบ, ความรุนแรง, จุดสิ้นสุด/ไฟล์ที่ได้รับผลกระทบ, หลักฐาน (สเนปช็อตหรือช่วงบรรทัด), สถานการณ์โจมตี, ข้อเสนอการแก้ไข

เวิร์กโฟลว์ทีละขั้นตอนสำหรับการตรวจ 30–60 นาที

กำหนดเวลา:

• 10 นาที เพื่อหาทิศทาง
• 15–30 นาที เพื่อติดตามการไหล
• 10 นาที เพื่อเขียนสรุป

เป้าหมายไม่ใช่ครอบคลุมสมบูรณ์ แต่เป็นชุดข้อค้นพบที่ทดสอบได้เล็ก ๆ

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

เวิร์กโฟลว์ที่ทำได้ในครั้งเดียว:

1. ร่างจุดเข้าและขอบเขตความเชื่อใจ ระบุเส้นทางสาธารณะ เส้นทางล็อกอิน เส้นทางแอดมิน เว็บฮุค อัปโหลด และ callback ของบุคคลที่สาม ทำเครื่องหมายจุดที่ข้อมูลข้ามจากผู้ใช้ควบคุมเป็นสิ่งที่เซิร์ฟเวอร์เชื่อถือ
2. สำหรับแต่ละจุดสิ้นสุดสำคัญ เขียนว่าที่ไหนพิสูจน์ตัวตนและเกิดขึ้นเมื่อไร หากเป็นมิดเดิลแวร์ ให้ยืนยันว่าทุกเส้นทางใช้มันจริงหรือไม่
3. ทำแบบเดียวกันกับการอนุญาต เลือกการกระทำเสี่ยงหนึ่งอย่าง (ดูข้อมูลผู้ใช้อื่น แก้ไขบทบาท ส่งออก ลบ) แล้วติดตามการตัดสินใจสิทธิ์จนถึงคิวรีฐานข้อมูล
4. ติดตามอินพุตของผู้ใช้จนถึงซิงค์ ปลายทาง เช่น SQL/ORM, การเรนเดอร์เทมเพลต, การรันคำสั่ง, การเรียก URL (SSRF), การเปลี่ยนเส้นทาง และเส้นทางไฟล์
5. สแกนการไหลของความลับขณะติดตาม มองหาโทเค็นในบันทึก โค้ดฝั่งไคลเอนต์ ข้อความแสดงข้อผิดพลาด และ dump ของสภาพแวดล้อม

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

การตรวจ Authn: พิสูจน์ว่าใครเป็นผู้ใช้

Authentication คือจุดที่แอปตัดสินว่า "คำขอนี้เป็นของบุคคลนี้" การตรวจแบบด่วนไม่จำเป็นต้องอ่านทุกบรรทัด แต่มองหาจุดที่ระบุอัตลักษณ์แล้วตรวจทางลัดและเส้นทางล้มเหลว

หาตำแหน่งขอบเขตความเชื่อใจ: ที่ไหนอัตลักษณ์ถูกสร้างหรือยอมรับครั้งแรก อาจเป็น cookie session, token JWT, API key, หรือ mTLS ที่ขอบเครือข่าย ถาม Claude Code ให้ชี้ไฟล์และฟังก์ชันที่เปลี่ยน "anonymous" เป็น user id และแสดงทุกเส้นทางอื่นที่ทำได้เหมือนกัน

การตรวจ Authn ที่ควรสแกน:

• ระบุจุดเข้า auth ทั้งหมด (เว็บล็อกอิน, โทเค็น API, การยืนยันบนมือถือ, การยืนยันบริการภายใน) และยืนยันว่ามันรวมอยู่ในโมเดลอัตลักษณ์เดียวกัน
• ตรวจล็อกอินและรีเซ็ตพาสเวิร์ดสำหรับ rate limit, การล็อกบัญชี, และการระบุผู้ใช้ (error ข้อความต่างกันหรือเวลาตอบต่างกันระหว่างบัญชีที่มีและไม่มี)
• ตรวจ session และ cookie: HttpOnly, Secure, SameSite, อายุการใช้งาน, การหมุนเมื่อล็อกอินและเปลี่ยนสิทธิ์, และการยกเลิกการใช้งานเมื่อ logout (ฝั่งเซิร์ฟเวอร์ ไม่ใช่แค่ลบ cookie)
• ตรวจ MFA และเส้นทางกู้คืนเพื่อให้แน่ใจว่าเส้นทางกู้คืนไม่อ่อนแอกว่า MFA (เช่น รีเซ็ตโดยอีเมลที่ข้าม MFA)
• ตรวจการบันทึกเมื่อ auth ล้มเหลว: ช่วยฝ่ายปฏิบัติการแต่ห้ามรั่วข้อมูลที่ช่วยผู้โจมตี (ห้ามมีคำว่า "user exists" หรือ dump โทเค็น)

ตัวอย่างปฏิบัติ: ถ้าอีเมลรีเซ็ตส่งกลับว่า "ไม่พบบัญชี" นั่นเป็นปัญหาการระบุผู้ใช้ แม้ข้อความจะทั่วไป ความต่างของเวลาในการตอบก็สามารถรั่วข้อมูลได้ ดังนั้นตรวจเวลาตอบด้วย

การตรวจ Authz: พิสูจน์ว่าผู้ใช้ได้รับอนุญาต

Authorization ทำความเสียหายมากที่สุดเมื่อผิด: "ผู้ใช้นี้ได้รับอนุญาตให้ทำการนี้บนทรัพยากรนี้หรือไม่?" การตรวจแบบด่วนควรพยายามทำลายสมมติฐานนั้นโดยตั้งใจ

เขียนบทบาทและสิทธิ์เป็นภาษาง่าย ๆ เช่น:

• เจ้าของเชิญสมาชิกได้
• สมาชิกแก้ไขโปรไฟล์ตัวเองได้
• ฝ่ายสนับสนุนดูรายละเอียดบิลได้แต่แก้แผนไม่ได้
• แอดมินลบโปรเจกต์ได้

แล้วยืนยันว่าทุกการกระทำที่สำคัญบังคับใช้ authz ฝั่งเซิร์ฟเวอร์ ไม่ใช่แค่ใน UI ปุ่มถูกซ่อนได้ แต่ผู้โจมตียังสามารถเรียก API ได้โดยตรง

สแกนอันที่มักเจอปัญหาจริง:

• หา endpoint/mutation ที่สร้าง ลบ ส่งออก เปลี่ยนบทบาท หรืเข้าถึงบิลลิ่ง
• สำหรับแต่ละอัน หาเช็กสิทธิ์ฝั่งเซิร์ฟเวอร์ (ไม่ใช่ฝั่ง frontend)
• มองหา ID ที่ผู้ใช้ควบคุม (projectId, userId, orgId) และยืนยันการเช็กความเป็นเจ้าของ
• ยืนยันว่าเส้นทางเฉพาะแอดมินล้มเหลวเมื่อ role หายไป
• ตรวจขอบเขต tenant: orgId/accountId ควรมาจากคอนเท็กซ์ session ไม่ใช่แค่จากอินพุตคำขอ

กลิ่น IDOR คลาสสิกง่าย ๆ คือคำขออย่าง GET /projects/{id} ที่ {id} ควบคุมโดยผู้ใช้ และเซิร์ฟเวอร์โหลดโดยไม่ตรวจว่าเป็นของผู้ใช้หรือตัวตนใน tenant เดียวกันหรือไม่

พรอมต์ที่บังคับคำตอบจริง:

"สำหรับ endpoint นี้ แสดงโค้ดที่ตัดสินการเข้าถึงอย่างแม่นยำ และระบุเงื่อนไขเฉพาะที่จะทำให้ผู้ใช้จาก orgId อื่นเข้าถึงได้ หากไม่มี ให้ชี้แจงว่าทำไมโดยระบุไฟล์และชื่อฟังก์ชัน"

การตรวจรับค่าเข้า: ป้องกันข้อมูลไม่คาดคิดเข้ามาตั้งแต่ต้น

ปัญหาเว็บแอปส่วนใหญ่เริ่มจากช่องว่าง: แอปยอมรับอินพุตที่นักพัฒนาไม่ได้คาดคิด ถือว่า "อินพุต" เป็นทุกอย่างที่ผู้ใช้หรือระบบอื่นควบคุมได้ แม้มันจะดูไร้พิษภัย

เริ่มจากการตั้งชื่ออินพุตสำหรับ endpoint ที่กำลังตรวจ:

• ค่าคิวรีและพาธใน URL
• ฟิลด์ในบอดี้คำขอ (รวม JSON ซ้อนกัน)
• เฮดเดอร์ (เฮดเดอร์ auth, content type, forwarded IP)
• คุกกี้
• การอัปโหลดไฟล์ (ชื่อ ขนาด ประเภท เมตาดาต้า)

การตรวจควรเกิดใกล้จุดที่ข้อมูลเข้ามา ไม่ใช่ลึกในตรรกะธุรกิจ ตรวจพื้นฐาน: ประเภท (string vs number), ความยาวสูงสุด, จำเป็นหรือไม่, และรูปแบบ (email, UUID, date)

สำหรับค่าที่รู้จัก เช่น role, status, หรือทิศทางการจัดเรียง ให้ใช้ allowlist จะยากต่อการบายพาสกว่าการพยายามบล็อกค่าที่ไม่ดี

ตรวจการจัดการข้อผิดพลาดด้วย หากแอปปฏิเสธอินพุต อย่าส่งค่าดิบกลับในคำตอบ บันทึก หรือ UI นั่นเป็นสาเหตุที่บั๊กการตรวจรับค่าน้อย ๆ กลายเป็นการรั่วข้อมูลหรือช่วยการฉีดโค้ด

แผนมินิ "อินพุตไม่ดี" สำหรับ endpoint เสี่ยง (ล็อกอิน, ค้นหา, อัปโหลด, การกระทำแอดมิน):

• สตริงยาวมาก (10,000+ ตัวอักษร)
• ประเภทผิด (อาเรย์แทนสตริง)
• ค่า enum ไม่คาดคิด
• อักขระพิเศษที่เปลี่ยนความหมาย
• ค่าว่างสำหรับฟิลด์ที่ต้องการ

ตัวอย่าง: พารามิเตอร์ sort ที่รับสตริงใด ๆ อาจกลายเป็นชิ้นส่วน SQL ได้ในภายหลัง การใช้ allowlist เช่น "date" หรือ "price" จะป้องกันชั้นของข้อผิดพลาดนี้ตั้งแต่ต้น

พื้นผิวการฉีดที่พบบ่อยให้สแกนเร็ว

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

ติดตามข้อมูลจากจุดเข้า (คิวรีพารามิเตอร์, เฮดเดอร์, คุกกี้, การอัปโหลด, ฟอร์มแอดมิน) ไปยังที่มันไปจบ

เป้าสแกนด่วน

มองหาแพทเทิร์นเหล่านี้และขอที่มาของการเรียกใช้และตัวอย่างเพย์โลดสำหรับแต่ละอัน:

• SQL injection: คิวรีที่ประกอบด้วยสตริง, ORDER BY ไดนามิก, ตัวบิลเดอร์ IN (...) ที่ join ค่าจากผู้ใช้
• XSS: การเรนเดอร์ HTML, เทมเพลต, พรีวิวมาร์กดาวน์, rich text editor ที่คิดว่า "sanitize ทีหลัง"
• Command injection: การเรียกเชลล์รอบการประมวลผลรูปภาพ, เครื่องมือ PDF, สำรองข้อมูล หรือขั้นตอน "convert" ที่ส่งแฟล็กจากผู้ใช้
• SSRF: ตัวดึง URL สำหรับเว็บฮุค, พรีวิวลิงก์, นำเข้าจาก URL, หรือเช็กสถานะภายในที่รับ URL จากผู้ใช้
• Path traversal: endpoint ดาวน์โหลดไฟล์, การแตก zip, และ pipeline อัปโหลดที่อ่านไฟล์ตามชื่อ

ระวังการดีซีเรียไรซ์และการฉีดเทมเพลตด้วย อะไรก็ตามที่พาร์ส JSON, YAML, หรือสตริงเทมเพลตจากผู้ใช้ อาจซ่อนพฤติกรรมเสี่ยง โดยเฉพาะเมื่อรองรับชนิดที่กำหนดเอง, นิพจน์ หรือการเรนเดอร์ฝั่งเซิร์ฟเวอร์

ถ้าฟีเจอร์รับ URL, ชื่อไฟล์, หรือข้อความที่ฟอร์แมตได้ ให้ถือว่ามันสามารถถูกใช้ในทางที่ผิดได้ จนกว่าจะพิสูจน์ด้วยเส้นทางโค้ดและการทดสอบ

การจัดการความลับ: หาแหล่งรั่วและการเก็บที่อ่อนแอ

ปัญหาความลับมักดังเมื่อตรวจเจอ โฟกัสที่ที่ความลับอยู่อาศัยและที่มันอาจถูกคัดลอกโดยไม่ตั้งใจ

ที่ที่ความลับมักโผล่:

• ตัวแปรสภาพแวดล้อมและไฟล์คอนฟิกแอป
• ผลลัพธ์ CI และบันทึกการ build (รวมถึงบันทึกการ deploy ที่ล้มเหลว)
• ไคลเอนต์บันเดิลและแอปมือถือ (ของที่ส่งให้ผู้ใช้)
• endpoint ดีบัก หน้า health และเครื่องมือแอดมิน
• หน้าข้อผิดพลาด, stack trace, และอีเวนต์การวิเคราะห์

แล้วบังคับคำตอบเชิงรูปธรรม: ถ้าความลับรั่ววันนี้ จะเกิดอะไรขึ้นต่อ? ระบบที่ดีมีเส้นทางโรเตชั่น (ออกคีย์ใหม่), การเพิกถอน (ปิดคีย์เก่า), และวิธี redeploy อย่างรวดเร็ว หากคำตอบคือ "เราจะเปลี่ยนทีหลัง" ให้ถือเป็นข้อค้นพบ

การให้สิทธิ์น้อยที่สุดเป็นทางชนะที่เร็ว เหตุการณ์แย่ลงเพราะคีย์มีสิทธิ์เกินควร มองหา user ฐานข้อมูลที่ DROP ตารางได้, โทเค็นบุคคลที่สามที่จัดการบัญชีได้, หรือ API key ที่ใช้ร่วมกันข้ามสภาพแวดล้อม ชอบหนึ่งคีย์ต่อบริการ ต่อสภาพแวดล้อม พร้อมสิทธิ์น้อยที่สุด

พรอมต์เช็คลัดที่นำไปวางใน Claude Code:

• "ค้นหาโทเค็น, รหัสผ่าน, และกุญแจส่วนตัวที่ hard-coded. ระบุพาธไฟล์และแพทเทิร์นสตริงที่จับคู่"
• "หาโค้ดที่ล็อกเฮดเดอร์คำขอ, คุกกี้, env vars, หรือออบเจ็กต์ข้อผิดพลาดทั้งก้อน แสดงบรรทัดล็อกและฟิลด์ที่อาจมีความลับ"
• "ตรวจว่าความลับสามารถลงใน snapshot, export, หรือ build artifacts หรือไม่ ระบุสิ่งที่ถูกจับและที่เก็บ"

สุดท้าย ยืนยันเกตเเร็ล: บล็อกความลับออกจาก source control (pre-commit/CI), และตรวจว่าการสำรองหรือ snapshot ไม่รวมรหัสผ่านแบบ plain-text หากแพลตฟอร์มรองรับ snapshot และ rollback ให้ยืนยันว่าความลับถูกฉีดที่รันไทม์ ไม่ได้ถูกฝังในอิมเมจที่บันทึก

พรอมต์ที่บังคับข้อค้นพบเชิงรูปธรรม (แบบคัดลอกวาง)

พรอมต์กว้างได้คำตอบกว้าง บังคับให้โมเดลยืนยันด้วยหลักฐาน: ตำแหน่งไฟล์จริง, เส้นทางการติดตามที่คุณทำได้, รีโปรที่รันได้, และสิ่งที่จะทำให้คำกล่าวผิด

ใช้แพทเทิร์นละข้อ แล้วให้มันแก้ไขหลังจากคุณยืนยันหรือปฏิเสธรายละเอียด

• หลักฐานระดับไฟล์: "ค้นหาในรีโปสำหรับ auth, sessions, tokens, และ middleware. ตั้งชื่อไฟล์, ฟังก์ชัน, และช่วงบรรทัดที่เกี่ยวข้อง อ้างสเนปช็อตที่เกี่ยวข้อง ถ้าไม่ชี้ไปที่โค้ด ให้ตอบว่า 'no evidence found'."
• ติดตามจากอินพุตถึงซิงค์: "เลือกอินพุตหนึ่งที่ผู้ใช้ควบคุม (เฮดเดอร์, คิวรี, บอดี้, คุกกี้). แสดงการไหลของข้อมูลทีละขั้นจากจุดเข้าไปยังที่มันถูกใช้ (SQL, HTML, เชลล์, เทมเพลต, เปลี่ยนเส้นทาง, เส้นทางไฟล์). ระบุแต่ละฟังก์ชันในห่วงโซ่"
• ขั้นตอนรีโปร: "ให้รีโปรขั้นต่ำด้วย curl (เมทอด, รูปแบบ URL, เฮดเดอร์, บอดี้). รวมรหัสสถานะที่คาดหวังและตัวอย่างการตอบสำเร็จ/ล้มเหลว ระบุสมมติฐาน (บทบาท, สถานะ auth)"
• ควบคุมผลบวกลวง: "อะไรที่จะพิสูจน์ว่าข้อค้นพบนี้ผิด? ระบุการตรวจ 2–3 อย่าง: flag คอนฟิก, ลำดับมิดเดิลแวร์, การตรวจ allowlist, คิวรีพาราเมไทซ์, การหนีของเฟรมเวิร์ก ถ้ามี ให้ชี้แจงว่าความเสี่ยงเปลี่ยนอย่างไร"
• การแก้ที่ปลอดที่สุด + การทดสอบ: "เสนอการเปลี่ยนแปลงที่เล็กที่สุดที่บล็อกปัญหาโดยไม่ทำลายเคสที่ถูกต้อง แล้วเขียนเทสต์หนึ่งชิ้นที่จะเพิ่ม (ชื่อ, จุดประสงค์, อินพุต, ผลลัพธ์ที่คาดหวัง). ถ้ามีการถ่วงดุล ให้ระบุ"

ถ้าผลลัพธ์ยังคลุมเครือ ให้บีบลง:

"ตอบเฉพาะด้วย: พาธไฟล์, ชื่อฟังก์ชัน, บรรทัดเสี่ยง, และผลกระทบหนึ่งประโยค"

ตัวอย่างจริง: เปลี่ยนความสงสัยเป็นปัญหาที่ยืนยันได้

จุดอัปเดตโปรไฟล์มักซ่อนบั๊กการควบคุมการเข้าถึง นี่คือกรณีสั้นที่คุณสามารถทำตามเช็คลิสต์นี้

สถานการณ์: endpoint API อัปเดตโปรไฟล์ผู้ใช้:

PATCH /api/profile?accountId=123 พร้อม JSON เช่น { "displayName": "Sam" }.

คุณขอให้ Claude Code หาฮэндเลอร์ ติดตามการใช้ accountId และพิสูจน์ว่าเซิร์ฟเวอร์ตรวจความเป็นเจ้าของหรือไม่

สิ่งที่มักพบ:

• Authn: คำขอต้องมี session หรือ token ดังนั้นดูเหมือนถูกป้องกัน
• Authz: ฮนด์เลอร์เชื่อ accountId จากคิวรีสตริงและอัปเดตบัญชีนั้นโดยไม่ตรวจว่าตรงกับผู้ใช้ที่ล็อกอินหรือไม่
• การตรวจรับค่าเข้า: displayName ถูก trim แต่ accountId ไม่ถูกตรวจว่าเป็นจำนวนเต็ม
• พื้นผิวการฉีด: SQL ถูกประกอบด้วยการเชื่อมสตริงเช่น "... WHERE account_id=" + accountId

รายงานที่ดีต้องชัดเจน:

• ความรุนแรง: สูง (IDOR + อาจมี SQL injection)
• หลักฐาน: คำขอที่ล็อกอินถูกต้องเปลี่ยนบัญชีอื่นเมื่อแก้ accountId; SQL ถูกสร้างจากอินพุตที่ไม่น่าเชื่อถือ
• แก้ไข: อย่าใช้ accountId จากไคลเอนต์ ใช้ id ของผู้ใช้ที่ผ่านการยืนยันทางฝั่งเซิร์ฟเวอร์; ทำ parameterize คิวรี
• ทดสอบ: พยายามอัปเดตบัญชีอื่น คาด 403; ปฏิเสธ accountId ที่ไม่ใช่ตัวเลข

หลังแพตซ์ ให้ตรวจเร็ว:

• ลองคำขอเดิมด้วย accountId อื่นและยืนยันว่าล้มเหลว
• ยืนยันในบันทึกว่าเซิร์ฟเวอร์ใช้ id ที่ยืนยันได้ ไม่ใช่พารามิเตอร์คิวรี
• ยืนยันว่าคิวรีใช้ placeholder/param ไม่ใช่การต่อสตริง
• รันเทสต์เชิงลบสำหรับอินพุตผิดรูป (ตัวอักษร, ตัวเลขยาวมาก)

กับดักที่ทำให้การตรวจแบบสั้นพลาดปัญหาจริง

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

กับดักทั่วไปอีกอย่างคือคำขอที่กำกว้าง "ทำการตรวจความปลอดภัย" มักให้รายงานทั่วไป การตรวจแบบสั้นต้องมีขอบเขตแคบ (endpoint ไหน บทบาทไหน ข้อมูลไหน) และรูปแบบผลลัพธ์เข้มงวด (ชื่อไฟล์, ฟังก์ชัน, บรรทัดเสี่ยง, รีโปรขั้นต่ำ)

กฎเดียวกันใช้กับผลลัพธ์จาก AI: อย่ายอมรับคำกล่าวโดยไม่ชี้ตำแหน่ง ถ้าข้อค้นพบไม่รวมตำแหน่งโค้ดและขั้นตอนทีละก้าว ให้ถือว่าไม่ได้รับการพิสูจน์

วิธีที่การตรวจแบบสั้นมักหลุด

กับดักเหล่านี้เกิดซ้ำ:

• สมมติว่าเป็น "เฉพาะแอดมิน" เพราะเป็นหน้าแอดมิน ไม่ใช่เพราะเซิร์ฟเวอร์บังคับ
• ขอผลการตรวจกว้าง ๆ แทนที่จะเป็น "แสดงคำขอที่ข้าม X ได้"
• ยอมรับว่า "เป็นไปได้ SQL injection" โดยไม่ระบุตำแหน่งการสร้างคิวรีและเส้นทางอินพุต
• ข้ามจุดเข้าไม่ชัดเจนอย่างเว็บฮุค งานตามเวลาที่กำหนด เครื่องมือนำเข้า และการกระทำภายในแอดมิน
• แก้ที่ปลายเหตุ (เพิ่มฟิลเตอร์หรือ regex) ขณะที่สาเหตุรากคือการขาดการตรวจรับค่าเข้า/การอนุญาต

ถ้าคุณจับตัวเองเพิ่มฟิลเตอร์หลังกรณีขอบมากขึ้น ให้หยุด การแก้จริงมักอยู่ก่อนหน้านั้น: ตรวจรับค่าที่ขอบ และทำให้การเช็กสิทธิ์ชัดเจนและรวมศูนย์

การตรวจด่วนที่ทำได้ก่อนส่ง

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

ห้าการตรวจด่วนที่คุ้มค่า:

• แรงเสียดทาน Authn: ลองล็อกอินพลาด 10 ครั้งต่อเนื่อง เห็น rate limit, การล็อกบัญชี หรือชะลอการตอบหรือไม่? บอกได้ไหมว่าอีเมลมีอยู่จากข้อความผิดพลาดหรือเวลาตอบ?
• Authz โดยการสลับ ID: เลือกทรัพยากรจริง (คำสั่ง, ใบแจ้งหนี้, โปรไฟล์). เปลี่ยน ID ใน URL, บอดี้ JSON, หรือตัวแปร GraphQL. ได้ข้อมูลที่ไม่ใช่ของคุณหรือไม่ แม้แต่ metadata เล็กน้อย?
• การป้องกันอินพุต: สำหรับฟิลด์สำคัญ (อีเมล, ชื่อ, ค้นหา, อัปโหลดไฟล์) ลองสตริงยาวมาก ยูนิโค้ดแปลก ๆ และประเภทที่ไม่คาดคิด (ตัวเลขแทนสตริง). บังคับความยาวและ allowlist ในที่ที่สำคัญหรือไม่?
• การรั่วความลับ: ค้นหาบันทึกล่าสุดและไคลเอนต์บันเดิลหาคีย์, API key, JWT, หรือ "Authorization: Bearer" ตรวจหน้าข้อผิดพลาดด้วย "มันแค่ในสเตจ" มักกลายเป็น "มันถูกส่งออกไปแล้ว"
• พื้นผิวการฉีด: มองหาการต่อสตริงเข้า SQL, ฟิลเตอร์, การเรนเดอร์เทมเพลต, คำสั่งเชลล์, หรือ URL เปลี่ยนเส้นทาง ถ้าอินพุตถึงหนึ่งในนี้โดยไม่มีการตรวจที่เข้มแข็ง ให้ถือว่าเสี่ยงจนกว่าจะพิสูจน์ได้

เขียน 3 การแก้หลักที่คุณส่งได้ในสัปดาห์นี้ อย่าเป็นลิสต์ความปรารถนา ตัวอย่าง: (1) เพิ่ม rate limiting ให้ล็อกอินและรีเซ็ตพาสเวิร์ด, (2) บังคับเช็กความเป็นเจ้าของฝั่งเซิร์ฟเวอร์ใน endpoint "get by id", (3) จำกัดความยาวอินพุตและปฏิเสธอักขระไม่คาดคิดสำหรับฟิลด์ค้นหา

ขั้นตอนต่อไป: ทำให้เช็คลิสต์นี้เป็นส่วนหนึ่งของกระบวนการบิวด์

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

เปลี่ยนทุกข้อค้นพบเป็นรายการ backlog ที่เข้าใจยาก:

• แก้ไข: จะเปลี่ยนโค้ดหรือคอนฟิกอย่างไร
• ทดสอบ: จะพิสูจน์ว่ามันแก้ได้อย่างไร (คำขอหนึ่งคำขอ, unit test หนึ่งชิ้น, ขั้นตอน QA หนึ่งอย่าง)
• เจ้าของ: คนหนึ่งคนที่รับผิดชอบ
• วันที่เป้าหมาย: รีลีสถัดไปหรือวันเฉพาะ
• หลักฐาน: ไฟล์/endpoint และคำขอหรือเพย์โหลดที่แสดงปัญหา

เลือกความถี่ที่เข้ากับความเสี่ยงและขนาดทีม สำหรับหลายทีม ทุกรีลีสคือดีที่สุด หากรีลีสบ่อย ทำการตรวจ 30–60 นาทีทุกเดือนและเช็กสั้นก่อนส่ง

ทำให้ทำซ้ำง่ายด้วยการสร้างแพ็กพรอมต์ที่ใช้ได้ซ้ำและเทมเพลตเช็คลิสต์ เก็บพรอมต์ที่เน้นผลลัพธ์เชิงรูปธรรม: แสดง route, guard, คำขอที่ล้มเหลว, และพฤติกรรมที่คาดหวัง เก็บแพ็กไว้ที่ที่ทีมทำงานอยู่แล้วเพื่อจะได้ไม่ถูกข้าม

ถ้าคุณสร้างแอปผ่านแชท ให้ฝังเช็คลิสต์ลงในการวางแผน เพิ่มบันทึกสั้น ๆ "สมมติฐานด้านความปลอดภัย" สำหรับ authn/authz, อินพุต, และความลับ แล้วรันการตรวจทันทีหลังเวอร์ชันแรกที่ใช้งานได้

Platforms like Koder.ai (koder.ai) can fit well with this habit because they let you iterate quickly while keeping review checkpoints. Using snapshots and rollback around risky changes makes it easier to ship security fixes without getting stuck when a change breaks behavior.