# สัปดาห์ที่ 12: ความปลอดภัยในการพัฒนาซอฟต์แวร์ และการจัดการความเสี่ยง

## วัตถุประสงค์การเรียนรู้

หลังจากเรียนในสัปดาห์นี้ นิสิตจะสามารถ:

1. **OWASP Top 10:** ระบุและอธิบายช่องโหว่ด้านความปลอดภัยที่พบบ่อยที่สุด 10 ประการ
2. **การเขียนโค้ดแบบปลอดภัย:** เขียนโค้ด JavaScript/TypeScript ที่ปลอดภัยจากช่องโหว่ทั่วไป
3. **การทดสอบความปลอดภัย:** ใช้เครื่องมือตรวจสอบ (npm audit, Snyk, OWASP ZAP) เพื่อค้นหาช่องโหว่
4. **การทบทวนความเสี่ยง:** ประเมินและอัพเดตบัญชีความเสี่ยงจากสัปดาห์ที่ 3 ด้วยข้อมูลจริง

---

## สารบัญ

### เนื้อหาหลัก (Lecture)

- [ส่วนที่ 1: OWASP Top 10 และหลักการเขียนโค้ด](#ส่วนที่-1-owasp-top-10-และหลักการเขียนโค้ดแบบปลอดภัย)
- [ส่วนที่ 2: หลักการเขียนโค้ดแบบปลอดภัย](#ส่วนที่-2-หลักการเขียนโค้ดแบบปลอดภัย)
- [ส่วนที่ 3: เครื่องมือและการทดสอบ](#ส่วนที่-3-เครื่องมือและการทดสอบความปลอดภัย)
- [ส่วนที่ 4: การทบทวนความเสี่ยง](#ส่วนที่-4-การทบทวนความเสี่ยง-และการบรรเทาความเสี่ยง)

### กิจกรรมและการบ้าน

- [กิจกรรม (Activities)](#🎯-กิจกรรม-activities)
  - [กิจกรรม 1: การทบทวนโค้ด (50 นาที)](#🕐-กิจกรรม-1-การทบทวนโค้ดด้านความปลอดภัย-50-นาที)
  - [กิจกรรม 2: Performance Testing (20 นาที)](#🕐-กิจกรรม-2-การทดสอบความปลอดภัยด้วย-npm-audit-และ-zap-20-นาที)
- [การบ้าน (Homework)](#📝-การบ้าน-homework)
- [การมอบหมายงาน D4](#📋-การมอบหมายงาน-d4--รายงานคุณภาพและความปลอดภัย)

### สรุปและทรัพยากร

- [การทบทวนหลักการ](#🔍-การทบทวนหลักการความปลอดภัย)
- [สรุป (Summary)](#📖-สรุป-summary)
- [Further Reading](#🎓-further-reading-ลึกขึ้นไป)
- [ทรัพยากรเพิ่มเติม](#📚-ทรัพยากรเพิ่มเติม)

---

### ส่วนที่ 1: OWASP Top 10 และหลักการเขียนโค้ดแบบปลอดภัย

#### 1.1 ความสำคัญของความปลอดภัยในการพัฒนา

**ตัวอย่างจากเหตุการณ์ที่เกิดขึ้นจริงในอดีต:**

```
เหตุการณ์การโจมตีทางไซเบอร์ที่มีผลกระทบสูง:

  - การโจมตี Twitter (2020): บัญชีผู้ใช้ 130 บัญชีถูกยึด
    สาเหตุ: การหลอกลวงทางสังคมอย่างง่าย ๆ และการรักษาความลับไม่ดี
    ผลกระทบ: สูญเสียสินทรัพย์ดิจิทัลมูลค่า 250,000 ดอลลาร์สหรัฐ

  - การรั่วไหลข้อมูล Equifax (2017): ข้อมูลประชาชน 147 ล้านคนเปิดเผย
    สาเหตุ: ช่องโหว่ที่ไม่ได้รับการแก้ไข (CVE-2017-5638)
    ผลกระทบ: จ่ายค่าชดใช้ 700 ล้านดอลลาร์สหรัฐ และความเสื่อมเชื่อ

  - การรั่วไหลข้อมูล Facebook-Cambridge Analytica (2018): ข้อมูลผู้ใช้ 87 ล้านคน
    สาเหตุ: API มีสิทธิ์เข้าถึงมากเกินไป และการปกป้องข้อมูลไม่เพียงพอ
    ผลกระทบ: บทลงโทษจากหน่วยงานกำหนดนโยบาย และสายผ่านการสูญเสียความเชื่อใจ

สำหรับนิสิต: ขนาดความเสี่ยงอาจเล็กลง แต่หลักการและแนวทางเหมือนกัน!
```

**ผลกระทบต่อธุรกิจจากความเสี่ยงด้านความปลอดภัย:**

```
ความเสี่ยงด้านความปลอดภัย → ผลกระทบต่อธุรกิจ

การรั่วไหลข้อมูล           → บทลงโทษจากหน่วยงานกำหนดนโยบาย (GDPR: 4% รายได้)
                           → การดำเนินคดีและการชดใช้
                           → การสูญเสียชื่อเสียงและความเชื่อใจ
                           → ลูกค้าหันไปใช้บริการอื่น

ระบบหยุดทำงาน              → สูญเสียรายได้ ($5,000-$300,000 ต่อชั่วโมง)
                           → ลูกค้าไม่พอใจ
                           → ข่าวเชิงลบและความเสื่อมเชื่อ

การลดความเร็วของแอปพลิเคชัน → การหน่วงเวลา 100 ms = สูญเสีย 1% รายได้
(จากการติดเชื้อมัลแวร์)      → ผู้ใช้ย้ายไปใช้บริการคู่แข่ง

การเสื่อมเชื่อใจ            → เมื่อเสียไป ยากที่จะได้คืน (เฉลี่ย 7 ปี)
                           → ค่าใช้จ่ายในการสร้างบันทึกลูกค้าเพิ่มขึ้น 25-30%
```

---

#### 1.2 OWASP Top 10 โครงข่ายของช่องโหว่ (ปี 2564/2021)

**OWASP** ย่อมาจาก Open Web Application Security Project  
คำประกาศวัตถุประสงค์: ช่วยให้องค์กรทั่วโลกพัฒนาซอฟต์แวร์ที่มีความปลอดภัยสูง

**ช่องโหว่ระดับสูง 10 ประการ:**

```
1. ขาดการควบคุมการเข้าถึง              → ผู้ใช้เข้าถึงข้อมูลที่ไม่ควรเข้า
   (Broken Access Control)

2. ความล้มเหลวทางการเข้ารหัส                      → ข้อมูลที่เข้ารหัสถูกถอดรหัสหรือรั่วไหล
   (Cryptographic Failures)

3. การรุกรานด้วยการฉีดโค้ด (Injection)             → SQL Injection หรือการรุกรานโค้ด
   (SQL Injection, Command Injection)

4. การออกแบบที่ไม่ปลอดภัย                       → ออกแบบโดยไม่คิดถึงความปลอดภัยตั้งแต่ต้น
   (Insecure Design)

5. การกำหนดค่าความปลอดภัยผิด                    → ค่าเริ่มต้นอ่อน หรือปิด debug mode ไว้
   (Security Misconfiguration)

6. ส่วนประกอบที่เสื่อมโทรมและเก่าแก่                → ใช้ไลบรารี/เฟรมเวิร์กที่มีช่องโหว่ที่ทราบแล้ว
   (Vulnerable/Outdated Dependencies)

7. ความล้มเหลวในการรับรองความเป็นตัวตนและการให้สิทธิ → การเข้าสู่ระบบอ่อนแอ หรือโทเคน JWT ที่ไม่ปลอดภัย
   (Authentication & Authorization Failures)

8. ความล้มเหลวด้านความสมบูรณ์ข้อมูล (Integrity)     → ข้อมูลถูกปรับเปลี่ยนโดย attacker
   (Software & Data Integrity Failures)

9. ความล้มเหลวในการบันทึกและการตรวจสอบ            → ไม่มีการบันทึก หรือไม่มีการแจ้งเตือนเมื่อระบบถูกโจมตี
   (Security Logging & Monitoring Failures)

10. การโจมตีจากเซิร์ฟเวอร์ (SSRF)                 → Attacker บังคับให้เซิร์ฟเวอร์ส่งคำขอไปยังเป้าหมาย
    (Server-Side Request Forgery)

ประเมินโดยพิจารณา: ความแพร่หลาย + ผลกระทบต่อธุรกิจ + ความเป็นไปได้ในการตรวจจับ + ความง่ายในการโจมตี
```

---

#### 1.3 ช่องโหว่ 3 อันดับแรกที่ศึกษา (บทเรียนโฟกัส)

#### ช่องโหว่ #1: ความหลวมแหลมในการควบคุมการเข้าถึง

**ตัวอย่าง: โค้ดที่มีปัญหา — ความหลวมแหลมในการควบคุม**

```javascript
// ปัญหา: จุดสิ้นสุด API ไม่ตรวจสอบสิทธิ์
// GET /api/users/:userId/profile
app.get("/api/users/:userId/profile", (req, res) => {
  const userId = req.params.userId;

  // ปัญหา: ไม่ตรวจสอบว่า ผู้ใช้ปัจจุบัน === userId ที่ร้องขอ หรือไม่
  // ผู้ใช้คนอื่นสามารถดู โปรไฟล์ อีเมล โทรศัพท์ ของคนอื่นได้

  const user = User.findById(userId);
  res.json({
    id: user.id,
    name: user.name,
    email: user.email, // เปิดเผยข้อมูล!
    phone: user.phone, // เปิดเผยข้อมูล!
    isAdmin: user.isAdmin, // ข้อมูลที่อ่อนไหว!
  });
});

// การโจมตี:
// GET /api/users/999/profile (ดูโปรไฟล์ของผู้ใช้อื่น)
// ตอบกลับ: { id: 999, email: 'victim@example.com', ... }
// → ข้อมูลส่วนตัวเปิดอบเผย!
```

**ที่ถูกต้อง — การตรวจสอบการเข้าถึง**

```javascript
// ที่ถูกต้อง: ตรวจสอบการให้สิทธิ์
app.get("/api/users/:userId/profile", authenticateUser, (req, res) => {
  const userId = req.params.userId;
  const currentUserId = req.user.id; // จากโทเคน JWT
  const isAdmin = req.user.isAdmin;

  // ตรวจสอบ: ผู้ใช้สามารถดูโปรไฟล์ของตัวเองเท่านั้น
  if (!isAdmin && userId !== currentUserId) {
    return res.status(403).json({ error: "Forbidden - Unauthorized" });
  }

  const user = User.findById(userId);

  // ทำความสะอาดการตอบกลับ: อย่าส่งข้อมูลที่ไม่จำเป็น
  res.json({
    id: user.id,
    name: user.name,
    // ไม่ส่ง: email, phone, isAdmin
  });
});

// การโจมตีถูกป้องกัน:
// GET /api/users/999/profile (เมื่อผู้ใช้ 123 ร้องขอ)
// ตอบกลับ: 403 Forbidden ← การเข้าถึงถูกปฏิเสธ!
```

**รายการตรวจสอบการป้องกัน:**

```
□ จุดสิ้นสุด API แต่ละจุดต้องตรวจสอบ: ผู้ใช้ปัจจุบันมีสิทธิ์หรือไม่?
□ การสืบค้นฐานข้อมูลต้องกรองตามผู้ใช้ปัจจุบัน:
    const user = User.findById(userId);
    if (user.ownerId !== currentUserId) throw 403;
□ อย่าเปิดเผยข้อมูลที่ไม่จำเป็น (อีเมล โทรศัพท์ เลขประจำตัว บัตรเครดิต)
□ ใช้ระบบสิทธิ์ตามบทบาท (ผู้ดูแลระบบ ≠ ผู้ใช้ทั่วไป)
□ ทดสอบ: พยายามเข้าถึงข้อมูลของผู้ใช้อื่น — ต้องล้มเหลว
```

**Key Takeaway:**

> **Always verify authorization before returning data.** ไม่มี "assume" ว่าผู้ใช้มีสิทธิ์ — ต้องตรวจสอบทุกครั้ง!

---

#### ช่องโหว่ #3: การรุกรานด้วยการฉีดโค้ด (Injection)

**ตัวอย่าง: โค้ดที่มีปัญหา — SQL Injection**

```javascript
// ปัญหา: การเชื่อมต่อสตริงโดยตรง (ห้ามทำ!)
app.get("/api/search", (req, res) => {
  const searchQuery = req.query.q;

  // เชื่อมต่ออินพุตของผู้ใช้โดยตรงเข้า SQL!
  const query = "SELECT * FROM users WHERE name = '" + searchQuery + "'";

  db.query(query, (err, results) => {
    res.json(results);
  });
});

// การโจมตี:
// GET /api/search?q=John' OR '1'='1
// คำสั่ง SQL กลายเป็น: SELECT * FROM users WHERE name = 'John' OR '1'='1'
// '1'='1' เป็นจริงเสมอ → คืนผู้ใช้ทุกคน!
// → การรั่วไหลข้อมูลมหาศาล!

// การโจมตีที่แย่กว่า:
// GET /api/search?q='; DROP TABLE users; --
// คำสั่ง: SELECT * FROM users WHERE name = ''; DROP TABLE users; --'
// → ฐานข้อมูลถูกลบ!
```

**ที่ถูกต้อง — استخدام Parameterized Queries (คำสั่งที่เตรียมไว้)**

```javascript
// ที่ถูกต้อง: ใช้ parameterized queries (ตัวยึดตำแหน่ง ?)
app.get("/api/search", (req, res) => {
  const searchQuery = req.query.q;

  // ตัวยึดตำแหน่ง ? = ผูกตัวแปร (ปลอดภัย!)
  const query = "SELECT * FROM users WHERE name = ?";

  db.query(query, [searchQuery], (err, results) => {
    if (err) {
      res.status(500).json({ error: "ข้อผิดพลาดฐานข้อมูล" });
    } else {
      res.json(results);
    }
  });
});

// การโจมตีถูกป้องกัน:
// GET /api/search?q=John' OR '1'='1
// ดำเนิน: SELECT * FROM users WHERE name = "John' OR '1'='1"
// → ค้นหาสตริงตัวอักษร "John' OR '1'='1" (ไม่พบ)
// → ไม่มี SQL Injection!
```

**รายการตรวจสอบการป้องกัน:**

```
SQL Injection:
□ ใช้ parameterized queries เสมอ (? หรือ :param)
□ ห้ามเชื่อมต่ออินพุตของผู้ใช้เข้า SQL strings
□ ใช้ ORM (Sequelize, TypeORM) ซึ่งทำการหลีกเลี่ยงโดยอัตโนมัติ

Command Injection:
□ หลีกเลี่ยงการใช้ exec/spawn ที่มีอินพุตของผู้ใช้
□ หากจำเป็น: ใช้ไลบรารี shell-escape
□ ตัวแบบสีขาวเท่านั้นสำหรับชื่อไฟล์ที่อนุญาต
□ ตรวจสอบอินพุต (regex check)
```

**Key Takeaway:**

> **Parameterized queries หลีกเลี่ยงจาก Injection ได้เกือบ 100%.** ห้ามใช้สตริง SQL + อินพุตของผู้ใช้!

---

#### ช่องโหว่ #6: ส่วนประกอบที่เสื่อมโทรมและเก่าแก่

**ตัวอย่าง: Dependency ที่ล้าสมัย**

```bash
# ตรวจสอบช่องโหว่
npm audit

# ผลลัพธ์:
# พบช่องโหว่จำนวน 12 อัน (5 อันระดับสูง, 7 อันระดับกลาง)
#
# ช่องโหว่ระดับสูง:
#   lodash@4.17.15 → Prototype Pollution
#   request@2.88.0 → Open Redirect
#   axios@0.18.0 → XXE vulnerability
```

**การแก้ไข:**

```bash
# อัพเดท dependency
npm audit fix              # แก้โดยอัตโนมัติได้
npm update                 # อัพเดทแบบแมนนวล

# ตรวจสอบแพคเกจเฉพาะ
npm info lodash@latest
```

**รายการตรวจสอบการป้องกัน:**

```
□ เรียกใช้ npm audit เป็นประจำ (ทีละสัปดาห์ใน CI/CD)
□ อัพเดท dependency ทีละเดือน
□ ตรวจสอบการเตือน Dependabot บน GitHub
□ ลบแพคเกจที่ไม่ใช้
□ ใช้เวอร์ชันคงที่สำหรับแพคเกจที่สำคัญ:
   "lodash": "4.17.21"  ← คงที่ ไม่ใช่ ^4.17.21
□ ตรวจสอบเพิ่มเติมก่อนอัพเดท
□ ทดสอบหลังอัพเดท!
```

**Key Takeaway:**

> **npm audit ควรรันประจำสัปดาห์** — ดีที่สุดคือตั้ง automation ใน CI/CD pipeline

---

### ส่วนที่ 2: หลักการเขียนโค้ดแบบปลอดภัย

#### 2.1 การตรวจสอบและทำความสะอาดอินพุต

**หลักการพื้นฐาน: ไม่เชื่ออินพุตของผู้ใช้เลย**

```javascript
// ปัญหา: รับอินพุตตามที่เป็น
app.post("/api/register", (req, res) => {
  const { email, password, name } = req.body;

  // ไม่มีการตรวจสอบ!
  // - อีเมลอาจไม่ถูกต้อง
  // - รหัสผ่านอาจอ่อนแอ
  // - ชื่ออาจมีโค้ด XSS

  User.create({ email, password, name });
  res.json({ success: true });
});

// ที่ถูกต้อง: ตรวจสอบอินพุตทั้งหมด
const { body, validationResult } = require("express-validator");

app.post(
  "/api/register",
  [
    body("email")
      .isEmail() // ต้องเป็นรูปแบบอีเมลที่ถูกต้อง
      .normalizeEmail(), // แปลงเป็นตัวพิมพ์เล็ก ลบช่องว่าง
    body("password")
      .isLength({ min: 8 }) // อย่างน้อย 8 ตัวอักษร
      .matches(/[A-Z]+/) // ต้องมีตัวพิมพ์ใหญ่
      .matches(/[0-9]+/), // ต้องมีตัวเลข
    body("name")
      .trim() // ลบช่องว่างในช่องต้นและปลาย
      .escape() // แปลง <, >, &, " เป็นสัญลักษณ์ HTML
      .isLength({ min: 2, max: 100 }),
  ],
  (req, res) => {
    // ตรวจสอบผลการตรวจสอบ
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return res.status(400).json({ errors: errors.array() });
    }

    const { email, password, name } = req.body;

    // อินพุตทั้งหมดได้รับการตรวจสอบแล้ว
    User.create({ email, password, name });
    res.json({ success: true });
  },
);
```

---

#### 2.2 การเข้ารหัสและการจัดเก็บรหัสผ่าน

**อย่าเคยเก็บรหัสผ่านตามปกติ!**

```javascript
// ปัญหา: รหัสผ่านตามปกติ
User.create({
  email: "user@example.com",
  password: "MyP@ssw0rd", // ตามปกติ!
});

// หากฐานข้อมูลรั่วไหล:
// → รหัสผ่านทั้งหมดถูกบุกรุก!
// → ผู้ใช้ใช้รหัสผ่านชุดเดียวสำหรับหลาย ๆ ที่
// → การยึด บัญชีอื่น ๆ ในหลาย ๆ ปลายทาง!

// ที่ถูกต้อง: เข้ารหัสรหัสผ่านด้วย bcrypt
const bcrypt = require("bcrypt");

const hashedPassword = await bcrypt.hash("MyP@ssw0rd", 10);
// ผลลัพธ์: $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcg7b3XeKeUxWdeS86AGR94AyIm

User.create({
  email: "user@example.com",
  password: hashedPassword, // เข้ารหัส!
});

// ตรวจสอบรหัสผ่านระหว่างการเข้าสู่ระบบ
const passwordMatch = await bcrypt.compare(
  "MyP@ssw0rd", // อินพุตของผู้ใช้
  user.password, // เข้ารหัสจากฐานข้อมูล
);

if (passwordMatch) {
  // รหัสผ่านถูกต้อง!
} else {
  // รหัสผ่านผิด!
}
```

**ทำไม Bcrypt?**

```
ประโยชน์ของ Bcrypt:
  - ช้าโดยเจตนา: 10^10 หมายถึงใช้เวลา 100ms ต่อครั้ง
    → การโจมตี brute force: 1M ครั้ง = 27 ชั่วโมง
  - เกลือ (Salt) โดยอัตโนมัติ: แต่ละแฮชไม่ซ้ำกัน
  - ต้านทานตาราธนู (Rainbow tables)
  - มาตรฐานของอุตสาหกรรม (ใช้โดย Google, Facebook, ฯลฯ)

ห้ามใช้:
  MD5 (เลิกใช้แล้ว ด่วน ง่ายต่อการแตก)
  SHA1 (เลิกใช้แล้ว)
  SHA256 เพียงอย่างเดียว (ต้องการเกลือ + stretching)
```

---

#### 2.3 การรับรองความเป็นตัวตนและการให้สิทธิ์

**วิธีปฏิบัติที่ดีที่สุดสำหรับ Session/JWT:**

```javascript
// ที่ถูกต้อง: JWT พร้อมการหมดอายุ
const jwt = require("jsonwebtoken");

app.post("/api/login", (req, res) => {
  // ... ตรวจสอบข้อมูลประจำตัว ...

  const token = jwt.sign(
    { userId: user.id, email: user.email },
    process.env.JWT_SECRET, // ความลับจากตัวแปรสภาพแวดล้อม ไม่ใช่ hardcoded!
    { expiresIn: "1h" }, // โทเคนหมดอายุใน 1 ชั่วโมง
  );

  res.cookie("token", token, {
    httpOnly: true, // ไม่สามารถเข้าถึงจาก JavaScript
    secure: true, // ส่งเฉพาะผ่าน HTTPS
    sameSite: "strict", // ป้องกัน CSRF
  });

  res.json({ success: true });
});

// Middleware: ตรวจสอบโทเคน
app.use((req, res, next) => {
  const token = req.cookies.token;

  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET);
    next();
  } catch (error) {
    res.status(401).json({ error: "Unauthorized" });
  }
});
```

---

### ส่วนที่ 3: เครื่องมือและการทดสอบความปลอดภัย

#### 3.1 npm audit — ตรวจสอบ Dependency

```bash
# สแกนหาช่องโหว่
npm audit

# ผลลัพธ์:
# ┌─────────────────────────────────────────────────┐
# │ npm security report                             │
# │ พบช่องโหว่จำนวน 12 อัน (5 สูง 7 กลาง)          │
# └─────────────────────────────────────────────────┘
#
# ช่องโหว่ระดับสูง:
#
# 1. lodash
#   คำอธิบาย: Prototype Pollution
#   แก้ไม่แล้วใน: 4.17.21
#   ข้อมูลความเสี่ยง: https://nvd.nist.gov/...
#
# 2. axios
#   คำอธิบาย: XXE ในการแยกวิเคราะห์ XML

# แก้ไขช่องโหว่
npm audit fix
```

---

#### 3.2 OWASP ZAP — การทดสอบความปลอดภัยแบบตรวจสอบ

**การติดตั้ง (ฟรี โอเพนซอร์ส):**

```bash
# ตัวเลือก 1: Docker
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t http://localhost:3000

# ตัวเลือก 2: ดาวน์โหลดจาก https://www.zaproxy.org/

# ตัวเลือก 3: ออนไลน์: https://owasp.org/www-community/attacks/DVWA
```

**รายการตรวจสอบการทดสอบแบบตรวจสอบ:**

```
การรับรองความเป็นตัวตนและการให้สิทธิ์:
  □ พยายามเข้าสู่ระบบด้วยรหัสผ่านผิด → ต้องล้มเหลว
  □ พยายามเข้าหน้าที่ป้องกัน โดยไม่เข้าสู่ระบบ → 401 ไม่ได้รับการอนุญาต
  □ โทเคน/เซสชันหมดอายุหลังจาก timeout
  □ Logout ลบเซสชัน

การเข้าถึง:
  □ ผู้ใช้ A ไม่สามารถดูข้อมูลส่วนตัวของผู้ใช้ B
  □ ผู้ใช้ทั่วไปไม่สามารถเข้าแผงผู้ดูแลระบบ
  □ แก้ไข URL เพื่อเข้าถึงบันทึกของผู้ใช้อื่น → 403 ไม่ได้รับการอนุญาต

การตรวจสอบอินพุต:
  □ SQL Injection: search?q='; DROP TABLE users; --
  □ XSS: name="<script>alert('xss')</script>"
  □ การอัพโหลดไฟล์: อัพโหลด .exe หรือ .php → ต้องปฏิเสธ

ข้อมูลที่ละเอียดอ่อน:
  □ ตรวจสอบการรับส่งข้อมูล (DevTools Network tab)
  □ รหัสผ่านส่งผ่าน HTTPS? (ผ่าน)
  □ โทเคนใน URLs? (ควรอยู่ใน headers)
  □ เปิดเผย API keys ใน JavaScript?

CSRF (Cross-Site Request Forgery):
  □ Forms มี CSRF token?
  □ โทเคนตรวจสอบบนเซิร์ฟเวอร์?
```

---

#### 3.3 Snyk — การตรวจสอบความปลอดภัยอย่างต่อเนื่อง

**การติดตั้ง (เฉพาะเจาะจง):**

```bash
# ติดตั้งในเครื่อง
npm install -g snyk

# ทดสอบหาช่องโหว่
snyk test

# ผลลัพธ์:
# ทดสอบ 1,248 dependency
# ผ่าน 1,236 แพคเกจสะอาด
# 12 แพคเกจมีช่องโหว่:
#   - 5 ระดับสูง
#   - 7 ระดับกลาง

# ตรวจสอบช่องโหว่
snyk monitor
# → สร้าง dashboard ที่ snyk.io
# → เตือนเมื่อพบช่องโหว่ใหม่
```

---

### ส่วนที่ 4: การทบทวนความเสี่ยง และการบรรเทาความเสี่ยง

#### 4.1 การทบทวนบัญชีความเสี่ยง (อัพเดตจากสัปดาห์ที่ 3)

> **Recall from Week 3:** ในสัปดาห์ที่ 3 เราได้ระบุความเสี่ยงทั้งหมดแล้ว (ตัวอย่าง: R-001, R-002, ..., R-006)
> **ตอนนี้ (สัปดาห์ที่ 12)** เรากำลังอัพเดตสถานะของความเสี่ยงเหล่านั้น — ทำซ้ำตามกระบวนการด้านล่าง:

**กระบวนการจัดการความเสี่ยง 5 ขั้นตอน**

```
ขั้นตอนที่ 1: ระบุความเสี่ยง (สัปดาห์ที่ 3)
ขั้นตอนที่ 2: วิเคราะห์ความเสี่ยง (ความน่าจะเป็น × ผลกระทบ)
ขั้นตอนที่ 3: จัดลำดับความเสี่ยง
ขั้นตอนที่ 4: วางแผนการบรรเทา
ขั้นตอนที่ 5: ตรวจสอบและควบคุมต่อเนื่อง ← เราอยู่ที่นี่ (สัปดาห์ที่ 12)
```

**ตัวอย่าง: การอัพเดทความเสี่ยง**

```
ความเสี่ยงดั้งเดิม (สัปดาห์ที่ 3):
┌─────────────────────────────────────┐
│ รหัส: R-006                         │
│ คำอธิบาย: พบช่องโหว่ด้านความปลอดภัย │
│ ในช่วงท้ายขั้นตอนการพัฒนา           │
│ ความน่าจะเป็น: ต่ำ (30%)            │
│ ผลกระทบ: สูง ($50,000)              │
│ ลำดับความสำคัญ: สูง                 │
│ การบรรเทา: OWASP code review,      │
│            penetration testing     │
│ ผู้รับผิดชอบ: Security Lead (Bob)    │
│ ไทม์ไลน์: สัปดาห์ที่ 12             │
└─────────────────────────────────────┘

อัพเดตในสัปดาห์ที่ 12:
สถานะ: บรรเทาแล้ว (สำเร็จ)
หลักฐาน:
  (สำเร็จ) โครงการตรวจสอบ OWASP เสร็จสิ้น
  (สำเร็จ) npm audit จัดการ 12 ช่องโหว่
  (สำเร็จ) การทดสอบความปลอดภัยด้วย ZAP เสร็จสิ้น
  (สำเร็จ) ไม่พบช่องโหว่ความเสี่ยงสูง

ความน่าจะเป็นใหม่: ต่ำ (15%) ← ลดลงจาก 30%
ผลกระทบใหม่: ปานกลาง ($20,000) ← ลดลงจาก $50,000

รายการดำเนินการที่เสร็จสิ้น:
  (สำเร็จ) ตั้งค่าการสแกนความปลอดภัยใน CI/CD
  (สำเร็จ) การฝึกอบรมทีมเกี่ยวกับการเขียนโค้ดแบบปลอดภัย
  (สำเร็จ) โมเดลการรับรองความเป็นตัวตนแบบ zero-trust

ความเสี่ยงที่เหลือ:
  - อัพเดต dependency (กำลังดำเนินการ)
  - การโจมตีทางสังคม (ไม่สามารถป้องกัน 100% ได้)

การทบทวนครั้งต่อไป: สัปดาห์ที่ 14 (ก่อนเปิดตัว)
```

**Common Mistakes:**

- ลืมอัพเดตเอกสารความเสี่ยง — → ต้องให้ evidence ว่าแก้ไขจริงๆ
- เขียนว่า "บรรเทาแล้ว" แต่ไม่มี proof (code, test results, etc.)
- ยอมรับความเสี่ยง (risk appetite) โดยไม่เห็นด้วยกับ stakeholders

---

#### 4.2 ความเสี่ยงใหม่ที่พบระหว่างการทดสอบ

**ตัวอย่าง: ความเสี่ยงเกิดใหม่**

```
ความเสี่ยงใหม่ที่พบ:
┌─────────────────────────────────────┐
│ รหัส: R-007 (ใหม่)                    │
│ คำอธิบาย: โทเคน Session อาจถูก        │
│ โจมตีผ่านช่องโหว่ XSS                   │
│ พบเมื่อ: การทดสอบความปลอดภัย (ZAP)    │
│ ความน่าจะเป็น: ปานกลาง (50%)          │
│ ผลกระทบ: สูง (รั่วไหลข้อมูลผู้ใช้)         │
│ ลำดับความสำคัญ: สูง                   │
│ การบรรเทา:                           │
│   - เพิ่ม httpOnly flag ให้กับ cookie   │
│   - นำไปใช้ CSP headers              │
│   - หลบหนี และ inputs ของผู้ใช้        │
│ ผู้รับผิดชอบ: API Lead (Charlie)       │
│ ไทม์ไลน์: สัปดาห์ที่ 13 (ก่อนเปิดตัว)       │
└─────────────────────────────────────┘

สถานะ: อาจจะมี แก้ไขที่กำลังดำเนินการ
```

---

## กิจกรรม (Activities)

### กิจกรรม 1: การทบทวนโค้ดด้านความปลอดภัย (50 นาที)

**วัตถุประสงค์:** ทีมทำการทบทวนโค้ด (peer code review) ด้วยการมองเห็นความปลอดภัย

**ขั้นตอน:**

**ส่วนที่ 1: เตรียมโค้ดที่มีปัญหา (10 นาที)**

จัดเตรียมโค้ด JavaScript ตัวอย่างที่มีปัญหาความปลอดภัย:

```javascript
// โค้ดที่มีปัญหา - ใช้สำหรับกิจกรรม

// ไฟล์: insecure-api.js
const express = require("express");
const app = express();

// ปัญหา 1: ไม่มีการตรวจสอบอินพุต
app.post("/api/users", (req, res) => {
  const { email, password, age } = req.body;

  // ใส่โดยตรงลงในฐานข้อมูลโดยไม่มีการตรวจสอบ!
  User.create({ email, password, age });
  res.json({ success: true });
});

// ปัญหา 2: SQL Injection
app.get("/api/search", (req, res) => {
  const query = "SELECT * FROM users WHERE name = '" + req.query.name + "'";
  db.query(query, (err, results) => {
    res.json(results);
  });
});

// ปัญหา 3: ไม่มีการเข้ารหัสรหัสผ่าน + ควบคุมการเข้าถึงที่ไม่ดี
app.get("/api/users/:id", (req, res) => {
  const user = User.findById(req.params.id);
  res.json(user); // คืนรหัสผ่าน!
});

// ปัญหา 4: ไม่มีการตรวจสอบการรับรองความเป็นตัวตน
app.delete("/api/users/:id", (req, res) => {
  User.deleteById(req.params.id);
  res.json({ success: true });
});
```

**ส่วนที่ 2: การทบทวนโค้ด (25 นาที)**

แบ่งกลุ่มคน 4 กลุ่ม แต่ละกลุ่มทบทวนปัญหา 1 ข้อ:

```
กลุ่ม 1: ปัญหาการตรวจสอบอินพุต
  วิธีการระบุ: ตรวจสอบการจัดการ body ของ POST
  วิธีแก้ไข: ใช้ express-validator
  ความเสี่ยง: SQL Injection, SSRF, ข้อมูลที่ไม่สะอาด

กลุ่ม 2: ปัญหา SQL Injection
  วิธีการระบุ: สตริง SQL แบบไดนามิก
  วิธีแก้ไข: Parameterized queries
  ความเสี่ยง: การรั่วไหลข้อมูล การประนีประนวมระบบ

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

กลุ่ม 4: ปัญหาการรับรองความเป็นตัวตน
  วิธีการระบุ: ไม่มีการตรวจสอบ token/session
  วิธีแก้ไข: เพิ่มส่วนกลาง (middleware) การรับรองความเป็นตัวตน
  ความเสี่ยง: การกระทำที่ไม่ได้รับหนุนใจ
```

**ส่วนที่ 3: นำเสนอผลการค้นหา (15 นาที)**

แต่ละกลุ่มนำเสนอ:

- ช่องโหว่คืออะไร?
- เป็นอันตรายอย่างไร?
- วิธีแก้ไข?
- กลยุทธ์การทดสอบ?

**ผลลัพธ์ที่คาดหวัง:**

- รายงานผลการทบทวนความปลอดภัย (1 หน้าต่อกลุ่ม)
- การแก้ไขที่เสนอ (ตัวอย่างโค้ด)
- แผนการทดสอบ

---

### กิจกรรม 2: การทดสอบความปลอดภัยด้วย npm audit และ ZAP (20 นาที)

**วัตถุประสงค์:** เรียกใช้เครื่องมือความปลอดภัยบนโครงการจริง

**ขั้นตอน:**

**ส่วนที่ 1: npm audit (5 นาที)**

```bash
# ในไดเรกทอรี่โครงการของคุณ
npm audit

# หากพบช่องโหว่:
npm audit fix

# ตรวจสอบสิ่งที่ถูกแก้ไข
npm audit --json > audit-report.json
```

**ส่วนที่ 2: การทบทวนรายการตรวจสอบความปลอดภัย (10 นาที)**

สำหรับโครงการของคุณ:

```
□ อินพุตของผู้ใช้ทั้งหมดได้รับการตรวจสอบหรือไม่?
□ รหัสผ่านถูกเข้ารหัสด้วย bcrypt หรือไม่?
□ การสืบค้นฐานข้อมูลใช้ parameterized queries หรือไม่?
□ ไม่มีความลับที่เขียนแบบ hardcode ในโค้ดหรือไม่?
□ มีส่วนกลางการรับรองความเป็นตัวตนหรือไม่?
□ มีการตรวจสอบสิทธิ์ที่จุดสิ้นสุด API ที่ป้องกันหรือไม่?
□ บังคับใช้ HTTPS หรือไม่?
□ ข้อความ error ไม่เปิดเผยข้อมูลที่ละเอียดอ่อนหรือไม่?
□ Dependency ได้รับการอัพเดต (npm audit) หรือไม่?
```

**ส่วนที่ 3: นำเสนอผลการค้นหา (5 นาที)**

```markdown
# รายงานการประเมินความปลอดภัย (โครงการ)

## ช่องโหว่ที่พบ

- [รายการจาก npm audit]

## รายการตรวจสอบความปลอดภัย

- [(ผ่าน) หรือ (ไม่ผ่าน) สำหรับแต่ละรายการ]

## การแก้ไข ที่ใช้

- [สิ่งที่ถูกแก้ไข]

## ปัญหาที่เหลืออยู่

- [ปัญหาใด ๆ ที่ยังไม่ได้แก้ไข]

## ขั้นตอนถัดไป

- [สิ่งที่ต้องแก้ไขก่อนเปิดตัว]
```

**ผลลัพธ์ที่คาดหวัง:**

- รายงาน npm audit
- รายการตรวจสอบความปลอดภัย (เสร็จสิ้น)
- สรุปการประเมิน (1 หน้า)

---

## การบ้าน (Homework)

### การบ้าน 1: การทบทวนการเข้ารหัส (บ้าน)

**ระยะเวลา:** 1.5 ชั่วโมง

**งาน:**

1. **ทบทวนโค้ดโครงการของคุณ:**
   - ตรวจสอบหาปัญหา OWASP Top 10
   - ตรวจสอบการตรวจสอบ input ทั้งหมด
   - ตรวจสอบการเข้ารหัสรหัสผ่าน
   - ตรวจสอบการควบคุมการเข้าถึง

2. **เรียกใช้เครื่องมือความปลอดภัย:**

   ```bash
   npm audit
   npm audit fix
   ```

3. **จัดทำเอกสารผลการค้นหา:**
   - รายงานการตรวจสอบความเข้ารหัส.md
   - ระบุช่องโหว่ที่พบ
   - การแก้ไขที่ใช้
   - ปัญหาที่เหลืออยู่

**กำหนดส่ง:**

- Security_Audit_Report.md (2-3 หน้า)
- audit-report.json (จาก npm audit)
- GitHub: docs/Security_Audit.md

---

### การบ้าน 2: อัพเดตบัญชีความเสี่ยง (บ้าน)

**ระยะเวลา:** 1 ชั่วโมง

**งาน:**

อัพเดตบัญชีความเสี่ยงของคุณจากสัปดาห์ที่ 3:

```markdown
# บัญชีความเสี่ยง - อัพเดต สัปดาห์ที่ 12

## ความเสี่ยงเดิม (อัพเดตสถานะ)

### R-006: ช่องโหว่ด้านความปลอดภัย

- **ความน่าจะเป็นเดิม:** 30%
- **ผลกระทบเดิม:** สูง ($50,000)
- **สถานะปัจจุบัน:** (สำเร็จ) บรรเทาแล้ว / กำลังแก้ไข / ยังไม่ได้จัดการ
- **หลักฐานของการบรรเทา:**
  - npm audit ผ่าน
  - การทบทวนโค้ดเสร็จ
  - การทดสอบความปลอดภัยเสร็จ
- **ความน่าจะเป็นใหม่:** 15% (ลดลง)
- **ผลกระทบใหม่:** ปานกลาง ($20,000)
- **การทบทวนครั้งต่อไป:** สัปดาห์ที่ 14 (ก่อนเปิดตัว)

## ความเสี่ยงใหม่ที่ค้นพบ

### R-007: [ชื่อความเสี่ยงใหม่]

- **คำอธิบาย:** ...
- **ความน่าจะเป็น:** ...
- **ผลกระทบ:** ...
- **แผนการบรรเทา:** ...
- **ผู้รับผิดชอบ:** ...

## กราฟการลดความเสี่ยง

[ตารางแสดง: R-001 (สำเร็จ) ปิด R-002 (สำเร็จ) ปิด R-003 ทำงานอยู่ ...]
```

**กำหนดส่ง:**

- Risk_Register_Week12_Update.md
- หลักฐานการบรรเทา (ลิงก์ไปโค้ด รายงานการทดสอบ)
- GitHub: docs/Risk_Management/Week12_Update.md

---

## การมอบหมายงาน: D4 — รายงานคุณภาพและความปลอดภัย

**กำหนดส่ง:** สิ้นสุดสัปดาห์ที่ 12

### D4.1: รายงานการประเมินความปลอดภัย (2 อันดับ)

**งาน:**

```
1. การประเมิน OWASP Top 10 (1 อันดับ)
   - ตรวจสอบโครงการของคุณเทียบกับ Top 10
   - ระบุช่องโหว่ใด ๆ ที่พบ
   - จัดทำเอกสารการแก้ไข
   - ให้หลักฐาน before/after

   ผลลัพธ์:
   - OWASP_Assessment.md (2-3 หน้า)
   - ภาพหน้าจอ:
     * เอกผลลัพธ์ npm audit (ก่อน)
     * npm audit fixed (หลัง)
     * การเปลี่ยนแปลงโค้ด:
       - ตัวอย่างการตรวจสอบ input
       - ตัวอย่าง SQL parameterization
       - ตัวอย่างการเข้ารหัสรหัสผ่าน
       - ตัวอย่างการตรวจสอบการเข้าถึง

2. รายงานการทดสอบความปลอดภัย (1 อันดับ)
   - จัดทำเอกสารการทดสอบความปลอดภัยที่ดำเนินการ
   - ผลลัพธ์ npm audit
   - รายการตรวจสอบการทดสอบแบบตรวจสอบ
   - สรุปการค้นหา

   ผลลัพธ์:
   - Security_Testing_Report.md
   - audit-report.json (ส่งออก จาก npm audit)
   - ภาพหน้าจอ/หลักฐานของการทดสอบ
```

---

### D4.2: อัพเดตการจัดการความเสี่ยง (1 อันดับ)

**งาน:**

```
1. อัพเดตบัญชีความเสี่ยง (0.5 อันดับ)
   - อัพเดตความเสี่ยงทั้งหมดจากสัปดาห์ที่ 3
   - ทำเครื่องหมายว่า: ปิด / บรรเทา / กำลังแก้ไข / เปิดอยู่
   - ให้หลักฐานสำหรับแต่ละสถานะ
   - เน้นความเสี่ยงที่เกี่ยวกับความปลอดภัย

   ผลลัพธ์:
   - Risk_Register_Final.md
   - กราฟการลดความเสี่ยง (การแสดงภาพ)
   - การมอบหมายผู้รับผิดชอบ
   - ไทม์ไลน์การแก้ไข

2. บทเรียนที่ได้เรียนรู้ - ความปลอดภัย (0.5 อันดับ)
   - ช่องโหว่ด้านความปลอดภัยที่คุณพบคืออะไร?
   - กระบวนการค้นหาทำงานอย่างไร?
   - ท่าทีด้านความปลอดภัยของทีมของคุณเป็น?
   - คำแนะนำสำหรับโครงการถัดไป

   ผลลัพธ์:
   - Security_Lessons_Learned.md (1 หน้า)
```

---

### D4.3: รายงานคุณภาพ และความปลอดภัยแบบรวม (2 อันดับ)

**งาน:**

รวม สัปดาห์ที่ 11 (คุณภาพ) + สัปดาห์ที่ 12 (ความปลอดภัย) เข้าเป็นรายงาน D4 ที่สมบูรณ์:

```
D4: รายงานคุณภาพ และความปลอดภัย
├── สรุปบรรยาย (1 หน้า)
│   - สถานะโดยรวม
│   - ตัวชี้วัดหลัก
│   - ปัญหาสำคัญ
│
├── ส่วนที่ 1: การประเมินคุณภาพ (จากสัปดาห์ที่ 11)
│   - ความครอบคลุมของโค้ด: 75%
│   - เกรดคุณภาพของโค้ด: B
│   - ความหนาแน่นของข้อบกพร่อง: 0.8/KLOC
│   - ตัวชี้วัด: LOC, Cyclomatic Complexity
│
├── ส่วนที่ 2: การประเมินความปลอดภัย (จากสัปดาห์ที่ 12)
│   - ช่องโหว่ OWASP: 0 ระดับวิกฤต
│   - Dependency: 12 fixed, 0 remaining
│   - การรับรองความเป็นตัวตน: (นำไปใช้แล้ว)
│   - การให้สิทธิ์: (บังคับใช้)
│
├── ส่วนที่ 3: การจัดการความเสี่ยง
│   - บัญชีความเสี่ยง: 15 รายการทั้งหมด
│   - ปิด: 8
│   - บรรเทา: 5
│   - เปิด: 2 (ยอมรับได้)
│   - กราฟการลดความเสี่ยง
│
├── ส่วนที่ 4: คำแนะนำ
│   - การปรับปรุง 5 อันดับแรก
│   - แผนการใช้งาน
│   - ไทม์ไลน์
│   - ความต้องการด้านทรัพยากร
│
└── ภาคผนวก
    - ภาพหน้าจอ
    - ผลลัพธ์เครื่องมือ (npm audit, coverage reports)
    - ลิงค์หลักฐาน
```

**ข้อกำหนด:**

- 8-12 หน้า ทั้งหมด
- ประตูแสดงผล/กราฟสรุป
- การแสดงภาพข้อมูล
- นำเสนอแบบวิชาการ
- คำแนะนำที่สามารถทำได้

**การให้คะแนน:**

- การประเมินความปลอดภัย: 2 อันดับ
- อัพเดตการจัดการความเสี่ยง: 1 อันดับ
- คุณภาพโดยรวม D4: 2 อันดับ
- **รวม: /5 อันดับ**

---

## การทบทวนหลักการความปลอดภัย

**จำไว้: Defense in Depth (การป้องกันแบบหลายชั้น)**

```
ชั้นของการป้องกัน:

1. ชั้น INPUT (ป้องกันมิให้ข้อมูลไม่ดีเข้าระบบ)
   - ตรวจสอบอินพุตทั้งหมด (ประเภท ความยาว รูปแบบ)
   - ทำความสะอาด input ของผู้ใช้ (ลบอักขระที่อันตราย)

2. ชั้น APPLICATION (ความปลอดภัยโดยธรรมชาติ)
   - รับรองความเป็นตัวตนของผู้ใช้ (คุณเป็นใครกันแน่)
   - ให้สิทธิ์การทำการ (คุณสามารถทำได้หรือไม่)
   - Parameterized queries (ป้องกัน injection)

3. ชั้น DATA (ปกป้องข้อมูลที่ละเอียดอ่อน)
   - เข้ารหัสรหัสผ่าน (bcrypt)
   - เข้ารหัสเขตข้อมูลที่ละเอียดอ่อน (AES-256)
   - HTTPS สำหรับการจัดส่ง

4. ชั้น INFRASTRUCTURE (ความปลอดภัยระบบ)
   - กฎ Firewall
   - การป้องกัน DDoS
   - การตรวจจับการรุกราน

หากชั้น 1 ล้มเหลว → ชั้น 2 จับมัน
หากชั้น 2 ล้มเหลว → ชั้น 3 จับมัน
หากชั้น 3 ล้มเหลว → ชั้น 4 จับมัน
```

---

## สรุป (Summary)

**OWASP Top 10 (ต้องทราบ):**

- ขาดการควบคุมการเข้าถึง — ทุกครั้งตรวจสอบสิทธิ์
- ความล้มเหลวทางการเข้ารหัส — เข้ารหัสข้อมูลที่ละเอียดอ่อน
- Injection — ใช้ parameterized queries
- การออกแบบที่ไม่ปลอดภัย — คิดถึงความปลอดภัยตั้งแต่แรก
- การกำหนดค่าความปลอดภัยผิด — ตรวจสอบการกำหนด
- ส่วนประกอบที่เสื่อมโทรม — ให้ dependency ปัจจุบัน
- ความล้มเหลวในการรับรองความเป็นตัวตน — การรับรองความเป็นตัวตนที่แข็งแกร่ง + การจัดเก็บที่ดี
- ความล้มเหลวด้านความสมบูรณ์ของข้อมูล — ตรวจสอบข้อมูล + การบันทึก
- ความล้มเหลวในการบันทึก — บันทึกเหตุการณ์ความปลอดภัย
- SSRF — ตรวจสอบการร้องขอเซิร์ฟเวอร์

**กระบวนการพัฒนาแบบปลอดภัย:**

1. **ออกแบบ:** คิดถึงความปลอดภัยตั้งแต่ต้น
2. **โค้ด:** ปฏิบัติตามหลักการเขียนโค้ดแบบปลอดภัย
3. **ทดสอบ:** การทดสอบความปลอดภัย (npm audit, ZAP)
4. **ปรับใช้:** การกำหนดค่าความปลอดภัย + การตรวจสอบ
5. **บันทึก:** การสแกนความปลอดภัยอย่างต่อเนื่อง

**Key Takeaway ส่วนที่ 4:**

> **Risk management ไม่ได้จบในสัปดาห์ที่ 3** — ต้อง continuously monitor, update, และ review ตลอดเวลา
> มี risk ที่ "เปิดอยู่" ก็ได้ — เพียงแต่ต้องทุกต้องเป็นที่ทราบ (acknowledged) และมี mitigation plan

**สิ่งที่ต้องจำ:**

```
"ความปลอดภัยไม่ใช่คุณสมบัติ มันคือกระบวนการ"
— ผู้เชี่ยวชาญด้านความปลอดภัยทั้งหมด

สร้างมันเข้าไปเลย อย่าติดกาวมันลงมา!
```

---

## Further Reading

ถ้าสนใจเรียนรู้เพิ่มเติมหลังสิ้นสัปดาห์ที่ 12:

### ระดับ 1: เข้าใจพื้นฐาน (สัปดาห์นี้)

- OWASP Top 10 overview
- Secure coding practices (bcrypt, parameterized queries, input validation)
- Basic testing (npm audit)

### ระดับ 2: ฝึกปฏิบัติ (ต่อจากนี้)

- Penetration testing basics (OWASP ZAP hands-on)
- JWT/Session management deep dive
- threat modeling workshops

### ระดับ 3: ขั้นสูง (ปีหน้า)

- Zero-trust architecture
- DevSecOps automation
- Incident response & forensics
- Compliance frameworks (GDPR, HIPAA, PCI-DSS)

---

## ทรัพยากรเพิ่มเติม

### การอ่านที่แนะนำ:

- [OWASP Top 10 เป็นทางการ](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)

### เครื่องมือ:

- [npm audit](https://docs.npmjs.com/cli/audit)
- [Snyk](https://snyk.io/)
- [OWASP ZAP](https://www.zaproxy.org/)
- [Burp Suite Community](https://portswigger.net/burp/communitydownload)

### ฝึกฝน:

- [WebGoat (OWASP)](https://owasp.org/www-project-webgoat/) — แอปพลิเคชันที่มีช่องโหว่เจตนาเพื่อเรียนรู้

---