คุณเข้าถึงฐานข้อมูลอย่างปลอดภัยด้วย PDO ได้อย่างไร?

Question

Accepted Answer

**PDO** (PHP Data Objects) คืออินเทอร์เฟซสมัยใหม่ของ PHP ที่ไม่ผูกติดกับฐานข้อมูลตัวใดตัวหนึ่ง (database-agnostic) สำหรับการเข้าถึงฐานข้อมูล คุณสมบัติที่สำคัญที่สุดของมันคือ **prepared statements** ซึ่งป้องกัน **SQL injection** อันเป็นแนวปฏิบัติด้านความปลอดภัยที่สำคัญยิ่งสำหรับโค้ดที่เกี่ยวข้องกับฐานข้อมูล

## การเชื่อมต่อด้วย PDO

```php
<?php
$pdo = new PDO(
    "mysql:host=localhost;dbname=app;charset=utf8mb4",
    $username, $password,
    [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,    // throw exceptions on errors
        PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, // fetch rows as associative arrays
    ]
);
```

PDO ทำงานได้กับฐานข้อมูลหลายตัว (MySQL, PostgreSQL, SQLite ฯลฯ) โดยใช้ API เดียวกัน การตั้งค่า `ERRMODE_EXCEPTION` ทำให้ข้อผิดพลาดของฐานข้อมูลโยน exception ที่สามารถดักจับได้

## แนวปฏิบัติที่สำคัญยิ่ง: prepared statements (ป้องกัน SQL injection)

```php
// ❌ NEVER do this — concatenating user input → SQL INJECTION vulnerability
$result = $pdo->query("SELECT * FROM users WHERE id = " . $_GET['id']);
// input "1 OR 1=1" or "1; DROP TABLE users" → disaster

// ✅ ALWAYS use prepared statements with bound parameters
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ? AND active = ?");
$stmt->execute([$_GET['id'], true]);            // parameters bound SAFELY
$user = $stmt->fetch();

// named parameters work too
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
$stmt->execute(["email" => $email]);
```

**Prepared statements** ส่ง SQL และข้อมูลแยกกัน ฐานข้อมูลจะมองพารามิเตอร์เป็นข้อมูลล้วน ๆ ไม่ใช่ SQL ที่จะถูกรันได้ ทำให้การ injection เป็นไปไม่ได้ ไม่ว่าผู้ใช้จะป้อนข้อมูลอะไรเข้ามาก็ตาม นี่คือสิ่งที่ต่อรองไม่ได้สำหรับทุก query ที่เกี่ยวข้องกับ input จากผู้ใช้

## การดึงผลลัพธ์และการดำเนินการอื่น ๆ

```php
$stmt->fetch();         // one row (associative array)
$stmt->fetchAll();      // all rows
$stmt->fetchColumn();   // a single value

// INSERT/UPDATE/DELETE — also use prepared statements
$stmt = $pdo->prepare("INSERT INTO users (name, email) VALUES (?, ?)");
$stmt->execute([$name, $email]);
$pdo->lastInsertId();   // the new row's ID
```

## ทรานแซกชัน (Transactions)

```php
$pdo->beginTransaction();
try {
    $pdo->prepare("UPDATE accounts SET balance = balance - ? WHERE id = ?")->execute([$amt, $from]);
    $pdo->prepare("UPDATE accounts SET balance = balance + ? WHERE id = ?")->execute([$amt, $to]);
    $pdo->commit();          // all-or-nothing
} catch (Throwable $e) {
    $pdo->rollBack();         // undo on failure
}
```

## ทำไมจึงสำคัญ

การเข้าถึงฐานข้อมูลอย่างปลอดภัยเป็นหนึ่งในแง่มุมที่สำคัญที่สุดด้านความปลอดภัยของการพัฒนา PHP และ **PDO กับ prepared statements คือแนวปฏิบัติพื้นฐานที่จำเป็น** ที่นักพัฒนา PHP ทุกคนต้องรู้

SQL injection ซึ่งเกิดจากการต่อ (concatenate) input จากผู้ใช้ที่ไม่น่าเชื่อถือเข้าไปใน SQL query โดยตรง เป็นหนึ่งในช่องโหว่บนเว็บที่พบบ่อยและสร้างความเสียหายมากที่สุด (เปิดทางให้ผู้โจมตีอ่าน แก้ไข หรือทำลายข้อมูล) และสามารถป้องกันได้อย่างสมบูรณ์ **Prepared statements** กับพารามิเตอร์ที่ผูกค่า (bound parameters) คือทางออก เพราะการส่งโครงสร้าง SQL และข้อมูลแยกกัน ทำให้ฐานข้อมูลมอง input จากผู้ใช้เป็นข้อมูลล้วน ๆ ที่ไม่มีวันถูกรันในฐานะ SQL จึงทำให้การ injection เป็นไปไม่ได้ ไม่ว่าจะป้อนอะไรเข้ามา

การเข้าใจว่าคุณต้องใช้ prepared statements **เสมอ** สำหรับทุก query ที่เกี่ยวข้องกับ input จากผู้ใช้ (ไม่ใช้การต่อสตริงเด็ดขาด) คือความรู้ที่ต่อรองไม่ได้และจำเป็นต่อความปลอดภัย

นอกเหนือจากความปลอดภัย อินเทอร์เฟซแบบ database-agnostic ของ PDO การจัดการข้อผิดพลาดด้วย exception การดึงผลลัพธ์ที่ยืดหยุ่น และการรองรับทรานแซกชัน ทำให้มันเป็นวิธีที่แข็งแกร่งและทันสมัยในการเข้าถึงฐานข้อมูลใน PHP

เนื่องจากการเข้าถึงฐานข้อมูลเป็นพื้นฐานของแอปพลิเคชันส่วนใหญ่ และ SQL injection ทั้งพบบ่อยและร้ายแรง การเชี่ยวชาญ PDO และวินัยที่เด็ดขาดในการใช้ prepared statements จึงเป็นหนึ่งในสิ่งสำคัญที่สุดที่นักพัฒนา PHP ต้องเข้าใจ มันคือเส้นแบ่งระหว่างแอปพลิเคชันที่ปลอดภัยกับแอปพลิเคชันที่เปราะบางต่อการโจมตีที่ร้ายแรงและเป็นที่รู้จักกันดี (เฟรมเวิร์กอย่าง Laravel ใช้ PDO อยู่เบื้องหลังร่วมกับ query builder/ORM ที่ปลอดภัย แต่หลักการพื้นฐานยังคงเดิม)