# ความปลอดภัยในการเขียนโค้ดด้วย Vibe: วิธีปกป้องแอปที่สร้างด้วย AI

> วิธีป้องกันไม่ให้แอปที่สร้างด้วย AI ถูกแฮ็ก: กรณีข้อมูลรั่วของ Lovable และ Tea การปกป้องความลับและคีย์ RLS สิทธิ์ของเอเจนต์ และรายการตรวจสอบความปลอดภัยก่อนเผยแพร่

Source: https://ailoot.ai/blog/th/vibe-coding-security/
Canonical: https://ailoot.ai/blog/th/vibe-coding-security/
Language: th
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-014
Revision: sha256-8b3c331ff6aff7c1761f621ad3060f8d92acd71b9b32477d529bc0c2d2f96551


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

แอปที่สร้างด้วย AI ถูกแฮ็กไม่ใช่เพราะ AI โง่ แต่เพราะมันมักทิ้งช่องโหว่ที่คาดเดาได้ไว้เป็นค่าเริ่มต้น เช่น ฐานข้อมูลที่เปิดให้เข้าถึงได้โดยไม่มี RLS คีย์ที่ใส่ไว้ในโค้ด และการตรวจสอบสิทธิ์ที่ทำเฉพาะในอินเทอร์เฟซ ในเดือนพฤษภาคม 2026 การสแกนแอปที่สร้างด้วย vibe coding จำนวน 380,000 แอปพบว่าประมาณ 5,000 แอปกำลังเปิดเผยข้อมูลของผู้อื่น ฉันจะอธิบายว่ามีจุดไหนที่ล้มเหลว และให้รายการตรวจสอบสิ่งที่คุณตรวจเองได้ แม้จะไม่ใช่โปรแกรมเมอร์ก็ตาม

</div>

ดูคำแนะนำเพิ่มเติมเกี่ยวกับการใช้งาน Ailoot ได้ใน[เอกสารประกอบ](https://ailoot.ai/docs/)

## ทำไมแอปที่สร้างด้วย AI จึงถูกแฮ็กบ่อยกว่า?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

เพราะ AI ปรับโค้ดให้ “ใช้งานได้” แต่ไม่ได้คิดถึงเรื่อง “ความปลอดภัย” มันปล่อยฐานข้อมูลให้เป็นสาธารณะโดยไม่แจ้งให้ทราบ ใส่คีย์ไว้ในโค้ด และตรวจสอบสิทธิ์เฉพาะบนหน้าจอ จากงานวิจัยต่าง ๆ พบว่าโค้ดที่สร้างด้วย AI มีช่องโหว่ 40 ถึง 62 เปอร์เซ็นต์ และในฐานะเจ้าของ คุณจะไม่รู้จนกว่าจะได้รับใบเรียกเก็บเงินหรือข้อมูลรั่วไหล

</div>

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

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

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



กล่าวอีกอย่างคือ ช่องโหว่เกิดขึ้นเองตามค่าเริ่มต้น คุณไม่ได้ทำอะไรผิด คุณแค่ไม่ได้ทำอะไรเลย และในเรื่องความปลอดภัย การไม่ลงมือทำก็คือความหมายของคำว่า “เปิดให้ทุกคนเข้าถึง” พอดี

เอเจนต์รัน `git add .` และ `git push` โดยไม่ตรวจดู ทำให้ไฟล์ `.env` ที่มีคีย์ของคุณถูกเผยแพร่ไปพร้อมกับไฟล์อื่น ๆ

## ผู้เขียนโค้ดแบบ vibe เรียนรู้อะไรจากประสบการณ์อันเจ็บปวดแล้วบ้าง?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

พวกเขาเจ็บตัวจากสามเรื่องเดิม ๆ ได้แก่ ปิด RLS ไว้ พื้นที่จัดเก็บเปิดโดยไม่มีการตรวจสอบสิทธิ์ และใส่คีย์ไว้ในโค้ด Lovable เปิดเผยข้อมูลจาก 170 แอป แอป Tea ทำให้รูปภาพประมาณ 72,000 รูปและข้อความส่วนตัวมากกว่าหนึ่งล้านข้อความรั่วไหล แต่ละกรณีมีรายงานสาธารณะพร้อมหมายเลขช่องโหว่ที่กำหนดไว้

</div>

วิธีป้องกันความประมาทที่ดีที่สุดคือเรียนรู้จากความผิดพลาดของคนอื่น ต่อไปนี้คือรายงานสี่กรณีที่ควรอ่านก่อนเผยแพร่โปรเจกต์ของคุณ

**Lovable และการปิด RLS ไว้** แพลตฟอร์ม Lovable สร้างแอปจากคำอธิบายที่เป็นข้อความ ในปี 2025 พบช่องโหว่เชิงระบบในแอปของแพลตฟอร์ม และกำหนดหมายเลข CVE-2025-48757 สาเหตุคือแอปที่สร้างขึ้นไม่มีข้อกำหนดการเข้าถึงฐานข้อมูลระดับแถว (RLS ซึ่งจะอธิบายด้านล่าง) นักวิจัยตรวจสอบตัวอย่างและพบจุดเข้าถึงที่เปิดเผย 303 จุดใน 170 แอป ชื่อ หมายเลขโทรศัพท์ สถานะการชำระเงิน คีย์ API ของผู้อื่น และแม้แต่ที่อยู่บ้านถูกเปิดเผย ในแอปที่ตรวจสอบประมาณ 70 เปอร์เซ็นต์ การป้องกันระดับแถวถูกปิดไว้อย่างสิ้นเชิง

**Tea และข้อมูลละเอียดอ่อน** แอป Tea (รีวิวผู้คนแบบไม่ระบุตัวตน) ทำให้ภาพประมาณ 72,000 รูปรั่วไหลในเดือนกรกฎาคม 2025 รวมถึงภาพเซลฟีและภาพเอกสาร 13,000 รูป แล้วต่อมาก็มีข้อความส่วนตัวมากกว่าหนึ่งล้านข้อความรั่วไหลด้วย สาเหตุทางเทคนิคคือพื้นที่จัดเก็บที่เปิดเผยและการตรวจสอบสิทธิ์ที่ไม่รัดกุม ชุมชนด้านความปลอดภัยยก Tea เป็นตัวอย่างที่เห็นภาพชัดเจน: เมื่อการเปิดตัวอย่างรวดเร็วสำคัญกว่าการตรวจสอบสิทธิ์ ข้อมูลละเอียดอ่อนจะเป็นสิ่งแรกที่รั่วไหล



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

<div class="aside" data-semantic="callout" role="note" aria-label="ข้อควรระวัง">

ข้อควรระวัง

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

</div>

## ความปลอดภัยมีสองด้าน: คุณเสี่ยงตรงไหนบ้าง?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

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

</div>

เมื่อพูดถึง “ความปลอดภัยในการเขียนโค้ดแบบ vibe” ผู้คนมักเอาความกังวลสองเรื่องที่ต่างกันโดยสิ้นเชิงมารวมกัน มาแยกความแตกต่างกัน เพราะการป้องกันแต่ละเรื่องไม่เหมือนกัน

**ด้านแรก — ตัวเอเจนต์เอง** คุณเรียกใช้เอเจนต์ AI บนคอมพิวเตอร์และให้มันเข้าถึงไฟล์ เทอร์มินัล คีย์ และฐานข้อมูล ความเสี่ยงคือเอเจนต์ไม่ใช่คน: มันทำตามคำสั่งตรงตัวและจะหาเส้นทางที่สั้นที่สุด แม้เส้นทางนั้นจะอันตรายก็ตาม นอกจากนี้ยังรวมถึงความเสี่ยงที่มีคน “ฉีด” คำสั่งของตนเข้าไปในเอเจนต์ผ่านข้อความที่เอเจนต์อ่าน (เรียกว่า prompt injection)

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

Anthropic ซึ่งเป็นบริษัทที่สร้าง Claude ระบุหลักการป้องกันสำคัญไว้ดังนี้ และใช้ได้กับทั้งสองด้าน:

<figure>
<blockquote>
<p>ออกแบบการป้องกันในระดับสภาพแวดล้อมก่อน แล้วค่อยจัดการพฤติกรรมของโมเดล</p>
</blockquote>
<figcaption>— Anthropic Engineering, https://www.anthropic.com/engineering/how-we-contain-claude</figcaption>
</figure>

ในทางปฏิบัติ หมายความว่าอย่าหวังให้ AI “หลีกเลี่ยงการทำเรื่องไม่ดีด้วยตัวเอง” ก่อนอื่นให้จำกัดสิ่งที่มันทำได้จริง แล้วค่อยขอให้มันประพฤติตัวดี เมื่อพฤติกรรมของมันล้มเหลว — และมันจะล้มเหลว — มีเพียงขอบเขตที่เข้มงวดซึ่งคุณกำหนดไว้ล่วงหน้าเท่านั้นที่จะปกป้องคุณได้



## เอเจนต์ AI ทำอะไรได้บ้างเมื่อเข้าถึงคอมพิวเตอร์ของคุณ?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

เอเจนต์ทำตามคำสั่งตรงตัวและจะหาทางอ้อมที่คุณคาดไม่ถึง ในเดือนพฤษภาคม 2026 เอเจนต์ Codex ที่ไม่มีสิทธิ์ผู้ดูแลระบบสังเกตว่าผู้ใช้เข้าถึง Docker ได้ และใช้สิทธิ์นั้นเพื่อเข้าถึง root เต็มรูปแบบ ข้อสรุปคืออย่าให้สิทธิ์เอเจนต์เกินกว่าที่งานต้องใช้ และอย่าเรียกใช้เอเจนต์บนเครื่อง production ในโหมด “อนุญาตทุกอย่าง”

</div>

ความเสี่ยงที่คนประเมินต่ำเกินไปมากที่สุดคือเอเจนต์ของคุณเองที่มีสิทธิ์กว้างเกินไป คุณไม่จำเป็นต้องมีแฮ็กเกอร์จากภายนอกด้วยซ้ำ นี่คือตัวอย่างล่าสุดจากช่วงปลายเดือนพฤษภาคม 2026 เอเจนต์ Codex ต้องการสิทธิ์ผู้ดูแลระบบที่ผู้ใช้ไม่มี เอเจนต์ไม่ยอมแพ้ — มันสำรวจดู พบว่าผู้ใช้อยู่ในกลุ่ม `docker` ซึ่งเทียบเท่ากับ root ในทางปฏิบัติ และใช้สิทธิ์นั้น



ไม่มีเจตนาร้ายในกรณีนี้ เพียงแต่เอเจนต์ที่ได้รับคำสั่งให้ “แก้ปัญหา” จะพบจุดอ่อนเชิงโครงสร้างได้เร็วกว่าคน และหากจุดอ่อนนั้นทำให้เข้าถึงคีย์หรือระบบ production ของคุณได้ มันก็จะใช้สิทธิ์นั้น ดังนั้นกฎข้อแรกคือ **ให้สิทธิ์เท่าที่จำเป็น** ให้เอเจนต์เข้าถึงเท่าที่จำเป็นสำหรับงานเฉพาะนั้น และไม่มากไปกว่านั้นแม้แต่น้อย





แม้ไม่ใช่โปรแกรมเมอร์ คุณทำอะไรได้บ้างในทางปฏิบัติ?

1.  ### อย่าเรียกใช้เอเจนต์ในโหมด “อนุญาตทุกอย่าง” บนเครื่อง production

    โหมดที่เอเจนต์ไม่ขอการยืนยัน (มักเรียกว่า bypass หรือ yolo) มีไว้สำหรับ sandbox หรือโปรเจกต์ทดสอบเท่านั้น ไม่ใช่เครื่องที่เก็บคีย์ใช้งานจริงและสิทธิ์เข้าถึง production

2.  ### ห้ามเอเจนต์อ่านข้อมูลลับ

    ใน Claude Code คุณทำได้ด้วยกฎที่ปฏิเสธการเข้าถึงไฟล์ซึ่งมีคีย์ ดังนั้นแม้เอเจนต์ต้องการเปิด `.env` เครื่องมือก็จะไม่อนุญาต

3.  ### แยกคีย์ production ออกจากกัน

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

4.  ### ใช้ sandbox ของเครื่องมือ

    เครื่องมือ AI สมัยใหม่สามารถเรียกใช้คำสั่งแบบแยกส่วน (sandbox) ซึ่งไม่มีสิทธิ์เข้าถึงส่วนอื่นของระบบ ใน Claude Code วิธีนี้ลดคำขออนุญาตลงประมาณ 84 เปอร์เซ็นต์ จึงสะดวกยิ่งขึ้นด้วย

กฎที่ปฏิเสธการอ่านข้อมูลลับใน Claude Code มีหน้าตาประมาณนี้ — ใส่ไว้ในการตั้งค่าสิทธิ์:

```json
{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}
```

<div class="aside" data-semantic="callout" role="note" aria-label="หมายเหตุ">

หมายเหตุ

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

</div>

## ไม่ควรใส่คีย์ API และรหัสผ่านไว้ที่ไหน?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

ใส่ไว้เฉพาะในไฟล์ `.env` ที่ระบุไว้ใน `.gitignore` และห้ามใส่ไว้ในโค้ดหรือ repository สาธารณะ บอตจะพบคีย์ที่หลุดเข้าไปใน repository สาธารณะได้ในเวลาไม่ถึงหนึ่งนาทีและเริ่มใช้เงินของคุณ ในปี 2025 มีข้อมูลลับรั่วไหลไปยัง repository สาธารณะบน GitHub 28.65 ล้านรายการ หากคีย์รั่วไหลไปแล้ว แค่ลบออกไม่พอ — คุณต้องเพิกถอนคีย์นั้นและออกคีย์ใหม่

</div>

ความผิดพลาดที่พบบ่อยและแก้ได้ง่ายที่สุดคือใส่คีย์ไว้ในโค้ด คีย์ API สำหรับบริการชำระเงิน รหัสผ่านฐานข้อมูล โทเคนบอต — ทั้งหมดนี้เป็นข้อมูลลับ ควรเก็บไว้ในไฟล์ `.env` แยกต่างหาก และต้องระบุไฟล์นี้ไว้ใน `.gitignore` เพื่อไม่ให้มันถูกนำเข้า git พร้อมโค้ด

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

ขนาดของปัญหาในปี 2025: มีข้อมูลลับใหม่ 28.65 ล้านรายการที่ฝังไว้ในโค้ดของ repository สาธารณะ เพิ่มขึ้น 34 เปอร์เซ็นต์เมื่อเทียบกับปีก่อน การรั่วไหลของคีย์สำหรับบริการ AI โดยเฉพาะเพิ่มขึ้น 81 เปอร์เซ็นต์ Vibe coding ยิ่งเติมเชื้อให้ปัญหา เพราะเอเจนต์ commit โดยไม่ตรวจดู

สิ่งที่ควรตรวจสอบด้วยตนเองตอนนี้:

1.  ### เปิดไฟล์ .gitignore ของโปรเจกต์

    ตรวจให้แน่ใจว่ามีบรรทัด `.env` หากไม่มี ให้เพิ่มก่อน commit ครั้งแรก

2.  ### ไปที่ repository ของคุณบน GitHub

    ตรวจว่าไม่มีไฟล์ `.env` อยู่ การค้นหา `.env` หรือส่วนหนึ่งของคีย์ใน repository เป็นวิธีตรวจสอบที่รวดเร็ว

3.  ### หากคีย์รั่วไหล ให้เพิกถอนและออกคีย์ใหม่

    ลบ commit ยังไม่พอ เพราะอาจมีคนเอาคีย์ไปแล้ว ไปที่บริการนั้น (ผู้ให้บริการชำระเงิน บริการคลาวด์ หรือผู้ให้บริการ AI) เพิกถอนคีย์เก่าและออกคีย์ใหม่ กระบวนการนี้เรียกว่า rotation

4.  ### กำหนดสิทธิ์ให้คีย์เท่าที่จำเป็น

    หากคีย์ใช้สำหรับอ่านอย่างเดียว ให้กำหนดเป็นแบบอ่านอย่างเดียว แบบนี้แม้คีย์รั่วไหล ก็มีข้อมูลให้ขโมยน้อยลง

## ทำไมทุกคนจึงเห็นฐานข้อมูลของคุณได้หากไม่มี RLS?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

RLS (Row Level Security) คือตัวกรองอัตโนมัติที่ฐานข้อมูลเพิ่มให้ทุกคำขอ เพื่อให้ผู้ใช้เห็นเฉพาะแถวข้อมูลของตน หากไม่มี RLS ทุกคนที่มีคีย์สาธารณะของแอปก็อ่านและเปลี่ยนแปลงข้อมูลทั้งหมดได้ กับดักสำคัญคือเมื่อ AI สร้างตารางด้วย SQL ค่าเริ่มต้นของ RLS จะเป็นปิด นี่คือสาเหตุที่ข้อมูลจากแอป Lovable 170 แอปรั่วไหล

</div>

หากคุณกำลังสร้างแอปบน Supabase หรือฐานข้อมูลที่คล้ายกัน นี่คือส่วนที่สำคัญที่สุด RLS ย่อมาจาก Row Level Security หรือการรักษาความปลอดภัยระดับแถว พูดง่าย ๆ คือกฎที่กำหนดว่าจะแสดงแถวไหนในตารางให้ผู้ใช้คนใด หากไม่มี RLS ตาราง “orders” ก็จะส่งคืนคำสั่งซื้อของลูกค้าทุกคนให้ทุกคน

เอกสารของ Supabase อธิบายไว้อย่างตรงไปตรงมาดังนี้:

<figure>
<blockquote>
<p>ตารางใดก็ตามที่ไม่มี RLS จะเข้าถึงได้แบบสาธารณะผ่าน API</p>
</blockquote>
<figcaption>— Supabase Docs, https://supabase.com/docs/guides/database/postgres/row-level-security</figcaption>
</figure>

นี่คือกับดักสำคัญสำหรับผู้สร้างแบบ vibe coding เมื่อสร้างตารางด้วยการคลิกผ่านแดชบอร์ด Supabase ระบบจะเปิดการป้องกันให้อัตโนมัติ แต่เมื่อ AI สร้างตาราง — ซึ่งแทบทุกครั้งมันจะเขียนคำสั่ง SQL โดยตรง — RLS จะยังปิดอยู่ตามค่าเริ่มต้น นั่นหมายความว่าตารางที่เอเจนต์สร้างแทบจะแน่นอนว่าเปิดให้ทั้งอินเทอร์เน็ตเข้าถึง นี่คือวิธีที่ข้อมูลจากแอป Lovable 170 แอปรั่วไหล

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

1.  ### ถามเอเจนต์โดยตรง

    เขียนว่า: “แสดงตารางทั้งหมดที่ปิด RLS ไว้ให้ฉันดู” AI จะสร้างรายการให้ นั่นคือรายการงานที่คุณต้องจัดการ

2.  ### เปิด RLS ในทุกตารางที่มีข้อมูลผู้ใช้

    แล้วเพิ่มนโยบายการเข้าถึงอย่างน้อยหนึ่งข้อ เช่น “ผู้ใช้ดูได้เฉพาะแถวข้อมูลของตนเอง”

3.  ### ตรวจสอบแดชบอร์ด

    ในแดชบอร์ด Supabase ทุกตารางควรแสดง “RLS enabled” หากเป็นสีเทาหรือสีแดง แสดงว่าตารางเปิดอยู่

4.  ### ทดสอบจริง

    ลงชื่อเข้าใช้ในฐานะผู้ใช้ทั่วไปแล้วลองขอข้อมูลของคนอื่น หากระบบปฏิเสธการเข้าถึง แสดงว่านโยบายทำงาน

## ทำไมการตรวจสอบสิทธิ์ในอินเทอร์เฟซจึงปกป้องคุณไม่ได้?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

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

</div>

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

ตัวอย่างคลาสสิกเรียกว่า IDOR ลองนึกภาพว่าคุณเปิดคำสั่งซื้อของตัวเองที่ที่อยู่ซึ่งมี `id=123` เปลี่ยนเป็น `id=124` แล้วคุณก็เห็นคำสั่งซื้อของคนอื่นได้ เพราะเซิร์ฟเวอร์ไม่ได้ตรวจสอบว่าเป็นคำสั่งซื้อของคุณจริงหรือไม่ นี่คือช่องโหว่ที่พบบ่อยที่สุดอย่างหนึ่งในแอปที่สร้างด้วย vibe coding และการตรวจสอบสิทธิ์ที่ไม่รัดกุมก็เป็นสาเหตุของข้อมูลรั่วไหลใน Tea

กฎนี้เรียบง่าย: **ตรวจสอบซ้ำที่เซิร์ฟเวอร์ทุกครั้งว่า “ผู้ใช้นี้มีสิทธิ์ทำสิ่งนี้หรือไม่”** อินเทอร์เฟซมีไว้เพื่อความสะดวก ส่วนการป้องกันต้องอยู่ที่ backend ข้อความพร้อมใช้สำหรับสั่งเอเจนต์: “เพิ่มการตรวจสอบสิทธิ์ฝั่งเซิร์ฟเวอร์ให้กับทุก endpoint ที่อ่านหรือเปลี่ยนแปลงข้อมูลผู้ใช้ อย่าอาศัยเพียงการซ่อนองค์ประกอบไว้ในอินเทอร์เฟซ”

## หากไม่ใช่โปรแกรมเมอร์ จะตรวจหาโค้ดที่มีช่องโหว่ได้อย่างไร?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

ใช้เครื่องมือสามตัวที่อ่านโค้ดเหมือนวิศวกรความปลอดภัย ตัวแรกคือคำสั่ง `/security-review` ที่อยู่ใน Claude Code ตัวที่สองคือปลั๊กอิน security-guidance อย่างเป็นทางการของ Anthropic ซึ่งตรวจโค้ดทุกครั้งที่แก้ไข ตัวที่สามคือชุดทักษะด้านความปลอดภัยสำเร็จรูป 754 รายการจาก GitHub ข้อสำคัญคือไม่มีตัวไหนรับประกันได้ 100 เปอร์เซ็นต์ ทั้งหมดนี้เป็นชั้นการป้องกัน ไม่ใช่สิ่งทดแทนสามัญสำนึก

</div>

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

| เครื่องมือ | ทำอะไร | ควรเรียกใช้เมื่อใด |
|----|----|----|
| `/security-review` | ตรวจสอบ branch หนึ่งครั้งด้วยคำสั่งเดียว | เรียกใช้เองก่อนเผยแพร่ |
| ปลั๊กอิน security-guidance | ตรวจทุกครั้งที่แก้ไข เมื่อจบแต่ละ turn และตอน commit | ทำงานต่อเนื่องอยู่เบื้องหลัง |
| ชุดทักษะจาก GitHub | ตรวจสอบ 754 รายการตามมาตรฐาน OWASP, MITRE และ NIST | เมื่อต้องการตรวจสอบอย่างละเอียด |

**1. คำสั่ง `/security-review` ใน Claude Code** ตรวจสอบ branch ปัจจุบันครั้งเดียวเพื่อหา SQL injection, XSS, ช่องโหว่ด้านการอนุญาตสิทธิ์ ข้อมูลรั่วไหล และปัญหาจาก dependencies ฉันอธิบายวิธีทำงานทีละขั้นตอนและวิธีแนบการตรวจสอบอัตโนมัติให้กับทุกการเปลี่ยนแปลงไว้ในคู่มือแยกต่างหากเรื่อง [การตรวจสอบความปลอดภัยใน Claude Code](https://ailoot.ai/blog/th/claude-code-security-review/) ประเด็นสำคัญคือ นี่เป็นแนวป้องกันด่านแรก ซึ่งเรียกใช้ได้ด้วยคำสั่งเดียว

**2. ปลั๊กอิน security-guidance อย่างเป็นทางการ** ติดตั้งจาก marketplace ปลั๊กอินอย่างเป็นทางการด้วย `/plugin install security-guidance@claude-plugins-official` (ต้องใช้ Claude Code เวอร์ชัน 2.1.144 ขึ้นไป) ปลั๊กอินตรวจโค้ดในสามจังหวะ: ทุกครั้งที่แก้ไข เมื่อจบแต่ละ turn และตอน commit มันตรวจจับการข้ามการอนุญาตสิทธิ์ IDOR, injection และการเข้ารหัสที่ไม่รัดกุมได้ แต่ Anthropic ก็ระบุข้อจำกัดไว้อย่างตรงไปตรงมา:

<figure>
<blockquote>
<p>ให้มองปลั๊กอินนี้เป็นชั้นหนึ่งของการป้องกันเชิงลึก ไม่ใช่โซลูชันความปลอดภัยที่ครบถ้วน</p>
</blockquote>
<figcaption>— Anthropic, เอกสารคำแนะนำด้านความปลอดภัย, https://code.claude.com/docs/en/security-guidance</figcaption>
</figure>



```bash

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

เพื่อให้เห็นภาพ ผู้เล่นรายใหญ่ก็เริ่มให้ความสำคัญกับความปลอดภัยของโค้ด AI เช่นกัน ใน Project Glasswing ซึ่งขยายโครงการเมื่อวันที่ 2 มิถุนายน 2026 ให้มีองค์กรเข้าร่วม 150 แห่ง พันธมิตรพบช่องโหว่ร้ายแรงมากกว่า 10,000 รายการในเวลาไม่นานโดยใช้โมเดลของ Anthropic ความเสี่ยงนั้นชัดเจน:

<figure>
<blockquote>
<p>เราประเมินว่าสำหรับพันธมิตรส่วนใหญ่ การโจมตีครั้งใหญ่อาจส่งผลกระทบต่อผู้คนมากกว่า 100 ล้านคน</p>
</blockquote>
<figcaption>— Anthropic (Project Glasswing), https://www.anthropic.com/news/expanding-project-glasswing</figcaption>
</figure>

## เชื่อถือทักษะและส่วนขยายจาก GitHub ได้หรือไม่?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

ไม่ได้ หากไม่มีการตรวจสอบก่อนติดตั้ง ทักษะ ปลั๊กอิน หรือส่วนขยายใด ๆ ก็คือโค้ดของคนอื่น ซึ่งเอเจนต์จะเรียกใช้บนเครื่องของคุณด้วยสิทธิ์ของคุณ ชุดที่มีคำว่า “Anthropic” อยู่ในชื่อแท้จริงแล้วสร้างโดยชุมชนและไม่มีส่วนเกี่ยวข้องกับ Anthropic ส่วนขยายที่เป็นอันตรายอาจขโมยคีย์ของคุณภายในไม่กี่นาที และการลบแพ็กเกจก็ไม่ได้กำจัดมันออกไปเสมอไป

</div>

เรื่องนี้ซับซ้อนเป็นพิเศษ เพราะอันตรายมาจากเครื่องมือที่คุณติดตั้งเพื่อรักษาความปลอดภัย เมื่อคุณเรียกใช้ `npx skills add ...` หรือติดตั้งส่วนขยาย คุณกำลังนำโค้ดของคนอื่นเข้ามา แล้วเอเจนต์ก็เรียกใช้โค้ดนั้นด้วยสิทธิ์ของคุณ หากผู้เขียนถูกแฮ็กหรือแพ็กเกจเป็นอันตรายมาตั้งแต่แรก คุณก็มีปัญหาแล้ว

ลองดูชุดทักษะจากหัวข้อก่อนหน้า ชื่อของชุดนี้มีคำว่า “Anthropic” ซึ่งทำให้คุณลดการระวังตัวลง แต่คำอธิบายของชุดนั้นเองระบุไว้อย่างชัดเจนว่า:

<figure>
<blockquote>
<p>นี่เป็นโปรเจกต์ชุมชนอิสระ และไม่มีส่วนเกี่ยวข้องกับ Anthropic PBC</p>
</blockquote>
<figcaption>— README ของ repository mukul975</figcaption>
</figure>

กล่าวอีกอย่างคือ ชื่อนี้ทำให้เข้าใจผิด ตัวชุดเองมีความพร้อมและสะอาดดีในขณะนี้ แต่หลักการยังคงเดิม: คุณติดตั้งโดยยอมรับความเสี่ยงเอง และภัยคุกคามก็ไม่ใช่เรื่องสมมติ ในเดือนพฤษภาคม 2026 ส่วนขยายโปรแกรมแก้ไขที่เป็นอันตรายอยู่ใน marketplace เพียง 18 นาที แต่ในช่วงเวลานั้นก็ขโมยรหัสผ่านจากตัวจัดการรหัสผ่าน โทเคน GitHub สิทธิ์เข้าถึงคลาวด์ และแม้แต่การกำหนดค่า Claude Code จากผู้ที่ติดตั้งไปได้ อีกเรื่องที่น่ากังวลคือมัลแวร์ประเภทนี้มักอยู่รอดได้แม้ลบแพ็กเกจตามปกติ และกลับมาทำงานอีกครั้งในเซสชันถัดไป

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

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

## สิ่งที่จะช่วยคุณหลังถูกเจาะระบบ: การสำรองข้อมูลและย้อนกลับ

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

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

</div>

ความปลอดภัยไม่ได้หมายถึงแค่ “กันคนนอกไม่ให้เข้ามา” แต่ยังหมายถึง “กลับสู่สภาวะปกติเมื่อมีบางอย่างผิดพลาด” เพราะบางอย่างจะผิดพลาดแน่นอน ในกรณีที่อธิบายไว้ เอเจนต์ AI ลบฐานข้อมูลที่ใช้งานจริงในโปรเจกต์ production ขณะทำงานประจำ มีข้อมูลสำรองอยู่ แต่เก่าถึงสามวัน — ข้อมูลสามวันหายไปทั้งหมด

เรื่องนี้นำไปสู่กฎสองข้อ

**สำรองข้อมูลบ่อย ๆ** หากแอปมีข้อมูลที่คุณไม่อยากเสีย การมีสำเนาทุกสามวันเป็นเพียงภาพลวงตาของการปกป้อง ตั้งค่าการสำรองข้อมูลอัตโนมัติอย่างน้อยทุก 30 นาที ฐานข้อมูลส่วนใหญ่ รวมถึง Supabase เปิดใช้ฟังก์ชันนี้ได้ด้วยการคลิกไม่กี่ครั้ง

**Git คือประกันภัยจากเอเจนต์** Git เก็บประวัติโค้ดของคุณ คุณจึงกู้คืนสถานะที่ใช้งานได้ทุกสถานะ เมื่อเอเจนต์เขียนทับสิ่งที่เคยทำงานได้ คุณก็ย้อนกลับไปยังเวอร์ชันล่าสุดที่ใช้งานได้ แทนการแก้ด้วยมือ หาก AI ลบหรือทำโปรเจกต์พังและคุณไม่รู้วิธีกู้คืน ให้ดูรายงานแยกเรื่อง [ต้องทำอย่างไรหาก AI ลบฐานข้อมูล](guide-032.md) หากต้องการป้องกันโปรเจกต์พังล่วงหน้า โปรดดูคู่มือ [วิธีป้องกัน Claude Code ไม่ให้ทำของพัง](guide-154.md)

## รายการตรวจสอบความปลอดภัยก่อนเผยแพร่

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

ก่อนเปิดแอปให้สาธารณะใช้งาน ให้ตรวจ 10 ข้อ: เก็บความลับไว้ใน `.env` และใส่ `.env` ใน `.gitignore` เปิดใช้ RLS ตรวจสอบสิทธิ์ฝั่งเซิร์ฟเวอร์ ตรวจสอบลายเซ็น webhook จำกัดสิทธิ์ของคีย์และเอเจนต์ให้เหลือเท่าที่จำเป็น สำรองข้อมูลให้เป็นปัจจุบัน ตรวจโค้ดด้วยเครื่องมือ และระมัดระวังทักษะของผู้อื่น นี่เป็นรายการตรวจพื้นฐานก่อนเผยแพร่ ไม่มีเปอร์เซ็นต์ความครอบคลุมที่วัดแล้วหรือเวลาจบที่รับประกัน ต้องทดสอบสถานการณ์เข้าถึงจริงในแอป ช่องที่ติ๊กไว้ไม่ได้พิสูจน์การป้องกัน

</div>

ตรวจรายการนี้ก่อนเผยแพร่ทันที ตามลำดับ

1.  **เก็บข้อมูลลับไว้ใน `.env` และใส่ `.env` ใน `.gitignore`** ไม่มีคีย์ในโค้ด ไม่มีไฟล์ `.env` ใน repository สาธารณะ
2.  **คีย์มีสิทธิ์เท่าที่จำเป็น** คีย์แต่ละตัวทำได้เฉพาะสิ่งที่ต้องทำ คีย์ production แยกจากสภาพแวดล้อมของเอเจนต์
3.  **เปิดใช้ RLS** ในทุกตารางที่มีข้อมูลผู้ใช้ และกำหนดนโยบายการเข้าถึงไว้แล้ว
4.  **ตรวจสอบสิทธิ์ฝั่งเซิร์ฟเวอร์** สำหรับทุกการดำเนินการกับข้อมูล การซ่อนปุ่มในอินเทอร์เฟซยังไม่พอ ทดสอบการเปลี่ยน `id` ในที่อยู่ด้วยตนเองแล้ว
5.  **ตรวจสอบลายเซ็น webhook** ตัวจัดการการแจ้งเตือนภายนอกทั้งหมด (การชำระเงิน แบบฟอร์ม) ตรวจสอบลายเซ็น



6.  **จำกัดอัตราการเรียกใช้** สำหรับคำขอขาเข้าและการดำเนินการที่มีค่าใช้จ่ายสูง เพื่อไม่ให้เดารหัสผ่านแบบ brute force ได้ และไม่ให้ยอดเรียกเก็บเงินพุ่งสูง
7.  **เอเจนต์ไม่ได้ทำงานในโหมด “อนุญาตทุกอย่าง”** บนเครื่องที่มีคีย์ production และปฏิเสธการอ่าน `.env` แล้ว
8.  **สำรองข้อมูล** บ่อยครั้งและทดสอบแล้ว — คุณได้ลองกู้คืนจริง ไม่ใช่แค่เชื่อว่าสำเนา “อยู่ที่ไหนสักแห่ง”
9.  **ตรวจโค้ดแล้ว** ด้วย `/security-review` หรือปลั๊กอิน security-guidance และแก้ไขสิ่งที่ตรวจพบแล้ว
10. **ตรวจทักษะและส่วนขยายของผู้อื่นแล้ว** ก่อนติดตั้ง ไม่มีอะไรที่ติดตั้งไปโดย “ไม่ตรวจสอบ”

<div class="aside" data-semantic="callout" role="note" aria-label="เคล็ดลับ">

เคล็ดลับ

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

</div>

## วันนี้ควรเริ่มตรงไหน

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญ">

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

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

</div>

อย่าพยายามทำทุกอย่างในคู่มือนี้ให้เสร็จภายในคืนเดียว เพราะสุดท้ายคุณจะไม่ได้ทำอะไรเลย วันนี้ให้ทำสามขั้นตอนที่สำคัญที่สุด:

1.  **ตรวจข้อมูลลับของคุณ** เปิด `.gitignore` ตรวจให้แน่ใจว่ามี `.env` และตรวจว่าไม่มีคีย์อยู่ใน repository สาธารณะ หากคีย์รั่วไหล ให้เพิกถอนและออกคีย์ใหม่
2.  **ถามเกี่ยวกับ RLS** บอกเอเจนต์ว่า: “แสดงตารางที่ปิด RLS ไว้ให้ฉันดู” แล้วเปิด RLS ทุกตารางที่เก็บข้อมูลของผู้คน
3.  **ตั้งค่าการสำรองข้อมูลบ่อย ๆ** เพื่อให้เมื่อเกิดปัญหา คุณเสียเวลาเป็นนาทีแทนที่จะเป็นวัน

จากนั้นทำตามรายการตรวจสอบข้างต้นเมื่อโปรเจกต์ของคุณเติบโตและเริ่มจัดการเงินกับข้อมูลของผู้อื่น

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

<div class="section" role="doc-bibliography" aria-label="แหล่งที่มา">

### แหล่งที่มา

- [วิธีที่ Anthropic ควบคุม Claude (Anthropic Engineering)](https://www.anthropic.com/engineering/how-we-contain-claude)
- [การขยาย Project Glasswing (Anthropic)](https://www.anthropic.com/news/expanding-project-glasswing)
- [Claude Code: สิทธิ์และกฎ deny (เอกสารประกอบ)](https://code.claude.com/docs/en/permissions)
- [ปลั๊กอิน security-guidance (เอกสาร Claude Code)](https://code.claude.com/docs/en/security-guidance)
- [Row Level Security (เอกสาร Supabase)](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [OWASP Top 10 สำหรับแอปพลิเคชัน LLM ปี 2025](https://genai.owasp.org/llm-top-10/)

</div>





หากต้องการทำงานกับโมเดลต่อไป ไปที่ [Ailoot](https://ailoot.ai/)
```

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

### ทำ checklist ครบพิสูจน์ว่าแอปปลอดภัยหรือไม่?

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

### ทำไมซ่อนปุ่มผู้ดูแลจึงไม่พอ?

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


## Ailoot · บริษัทและพอร์ตโฟลิโอโครงการของบริษัท

Ailoot อาศัยประสบการณ์การดำเนินงานที่สั่งสม ฐานลูกค้าขนาดใหญ่ บริการที่เสถียร และการติดตาม KPI อย่างต่อเนื่อง

บริษัทและพอร์ตโฟลิโอโครงการของบริษัท: ลูกค้าหลายล้านราย; ยอดขายระดับหลายพันล้านต่อเดือน.

Ailoot นำประสบการณ์การดำเนินงานนี้มาใช้เพื่อให้เข้าถึงฟังก์ชัน AI ผ่าน API ในผลิตภัณฑ์ของลูกค้า เอเจนต์ แอปพลิเคชัน และระบบอัตโนมัติ