Lỗ Hổng Bảo Mật PHP: 11 Lỗi Phổ Biến Và Cách Phòng Chống (2026)

Phần lớn website PHP bị xâm nhập không phải vì kẻ tấn công quá giỏi, mà vì code có những lỗi rất quen thuộc: ghép chuỗi vào câu SQL, in dữ liệu người dùng ra HTML, cho upload file không kiểm tra, hoặc chạy phiên bản PHP đã hết hỗ trợ. Bài viết này tổng hợp các lỗ hổng bảo mật PHP thường gặp nhất năm 2026, kèm ví dụ code không an toàn và an toàn để bạn đối chiếu và sửa ngay trong dự án của mình.

Nội dung hướng tới lập trình viên PHP và người đang tự quản trị website. TeamDevDesign bám theo OWASP Top 10:2025 và tài liệu chính thức trên php.net. Đây là bài phòng thủ: chúng tôi chỉ giải thích cơ chế ở mức khái niệm, không đưa payload khai thác.

Mục lục

• Lỗ hổng bảo mật PHP là gì và vì sao vẫn nóng năm 2026
• 1. SQL injection: dùng PDO prepared statements
• 2. XSS: escape đầu ra và Content-Security-Policy
• 3. CSRF: token cho mọi form thay đổi dữ liệu
• 4. Upload file không an toàn
• 5. LFI/RFI và path traversal
• 6. Command injection
• 7. Insecure deserialization
• 8. Session và mật khẩu
• 9. Cấu hình php.ini cho production
• 10. Cập nhật phiên bản PHP được hỗ trợ
• 11. Dùng framework như Laravel
• Checklist lập trình PHP an toàn
• Câu hỏi thường gặp

Lỗ hổng bảo mật PHP là gì và vì sao vẫn nóng năm 2026

Lỗ hổng bảo mật PHP là điểm yếu trong code PHP, trong cấu hình máy chủ hoặc trong chính trình thông dịch PHP, cho phép người khác làm điều họ không được phép: đọc dữ liệu, sửa dữ liệu, chiếm phiên đăng nhập hoặc chạy lệnh trên server. Có hai nhóm cần phân biệt:

• Lỗi trong code ứng dụng: SQL injection, XSS, CSRF, upload file, include file... Đây là phần lập trình viên kiểm soát trực tiếp và là trọng tâm của bài.
• Lỗi trong bản thân PHP: chỉ khắc phục được bằng cách cập nhật phiên bản. Ví dụ gần nhất: ngày 21/10/2026, php.net phát hành cảnh báo về hai lỗ hổng thực thi mã từ xa không cần xác thực (CVE-2026-109618 và CVE-2026-109619, điểm CVSS v4.0 là 9.2). Bản vá có trong PHP 8.2.35, 8.3.36, 8.4.27 và 8.5.12. Theo advisory chính thức, cập nhật lên bản đã vá là cách khắc phục đầy đủ duy nhất. Ngày 23/10/2026, php.net tiếp tục khuyến nghị tạm đặt session.upload_progress.enabled=0 cho tới bản sửa lỗi kế tiếp (CVE-2026-115560, chi tiết sẽ công bố cùng bản phát hành). Hãy theo dõi php.net để cập nhật kịp thời.

Danh sách OWASP Top 10 phiên bản mới nhất là bản 2025. So với bản 2021, có thêm hai hạng mục mới là Software Supply Chain Failures và Mishandling of Exceptional Conditions. Bảng dưới đây ánh xạ các lỗi PHP trong bài với hạng mục OWASP tương ứng:

Nếu bạn dùng WordPress, rất nhiều lỗi ở trên xuất hiện trong plugin và theme. Xem thêm bài các lỗ hổng bảo mật WordPress phổ biến và cách xử lý lỗ hổng plugin WordPress để có góc nhìn từ phía người quản trị.

1. SQL injection: chống SQL injection PHP bằng PDO prepared statements

SQL injection xảy ra khi dữ liệu người dùng được ghép thẳng vào câu SQL. Khi đó, dữ liệu có thể làm thay đổi cấu trúc câu lệnh: lọc sai điều kiện, đọc bảng khác hoặc xóa dữ liệu. Đây vẫn là một trong những lỗ hổng bảo mật PHP gây thiệt hại lớn nhất vì nó chạm trực tiếp vào cơ sở dữ liệu.

Code không an toàn

// KHÔNG AN TOÀN: ghép chuỗi trực tiếp vào câu SQL
$email = $_POST['email'];
$sql = "SELECT id, name FROM users WHERE email = '$email'";
$user = $pdo->query($sql)->fetch();

Code an toàn với PDO

// AN TOÀN: PDO + prepared statement
$pdo = new PDO('mysql:host=localhost;dbname=app;charset=utf8mb4', $dbUser, $dbPass, [
    PDO::ATTR_ERRMODE            => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
    PDO::ATTR_EMULATE_PREPARES   => false,
]);

$stmt = $pdo->prepare('SELECT id, name FROM users WHERE email = :email');
$stmt->execute(['email' => $_POST['email'] ?? '']);
$user = $stmt->fetch();

Prepared statement gửi cấu trúc câu SQL và dữ liệu tách riêng, nên dữ liệu chỉ được xem là giá trị. Ba điểm hay bị bỏ qua:

• Đặt charset=utf8mb4 trong DSN thay vì chạy SET NAMES riêng.
• Đặt PDO::ATTR_EMULATE_PREPARES => false để dùng prepared statement thật của MySQL khi có thể.
• Tên bảng, tên cột, chiều ORDER BY không bind được bằng placeholder. Hãy dùng danh sách cho phép (allowlist).

// Tên cột / chiều sắp xếp: không bind được, hãy dùng allowlist
$sortable = ['created_at', 'price', 'name'];
$sort  = in_array($_GET['sort'] ?? '', $sortable, true) ? $_GET['sort'] : 'created_at';
$order = (($_GET['order'] ?? '') === 'asc') ? 'ASC' : 'DESC';
$stmt = $pdo->prepare("SELECT * FROM products ORDER BY $sort $order LIMIT :limit");
$stmt->bindValue('limit', 20, PDO::PARAM_INT);
$stmt->execute();

Lưu ý: mysqli_real_escape_string() hay addslashes() không phải giải pháp chính. Chúng dễ dùng sai ngữ cảnh (ví dụ giá trị số không có dấu nháy). Hãy ưu tiên prepared statement, xem thêm tài liệu PDO trên php.net.

2. XSS: escape đầu ra bằng htmlspecialchars và thêm Content-Security-Policy

Cross-site scripting (XSS) xảy ra khi website in dữ liệu người dùng ra trang mà không mã hóa. Trình duyệt sẽ hiểu dữ liệu đó là HTML hoặc JavaScript và chạy nó trong phiên của người xem, từ đó có thể đánh cắp phiên đăng nhập hoặc thực hiện thao tác thay họ.

Code không an toàn

<!-- KHÔNG AN TOÀN: in thẳng dữ liệu người dùng -->
<p>Kết quả tìm kiếm cho: <?= $_GET['q'] ?></p>

Code an toàn

<?php
function e(?string $value): string
{
    return htmlspecialchars($value ?? '', ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, 'UTF-8');
}
?>
<!-- AN TOÀN: escape ngay tại chỗ xuất ra HTML -->
<p>Kết quả tìm kiếm cho: <?= e($_GET['q'] ?? '') ?></p>
<input type="text" name="q" value="<?= e($_GET['q'] ?? '') ?>">

Nguyên tắc là escape ở đầu ra, theo đúng ngữ cảnh. Từ PHP 8.1, cờ mặc định của htmlspecialchars() đã là ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML401 (theo php.net), nhưng bạn vẫn nên ghi rõ ENT_QUOTES và 'UTF-8' để code chạy đúng trên mọi phiên bản và cấu hình default_charset. Với dữ liệu đưa vào JavaScript, hãy dùng json_encode() với các cờ JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT; với URL, kiểm tra scheme và dùng rawurlencode() cho từng tham số.

Thêm lớp bảo vệ: Content-Security-Policy

CSP là header yêu cầu trình duyệt chỉ chạy script từ nguồn bạn cho phép. Nếu lỡ có một điểm XSS lọt qua, CSP giúp giảm đáng kể tác động. Bắt đầu bằng chế độ Content-Security-Policy-Report-Only để theo dõi, sau đó mới áp dụng thật.

// Gửi header CSP (đặt trước mọi output)
header("Content-Security-Policy: default-src 'self'; script-src 'self'; "
     . "object-src 'none'; base-uri 'self'; frame-ancestors 'self'");
header('X-Content-Type-Options: nosniff');

Tham khảo cấu hình chi tiết trong OWASP CSP Cheat Sheet.

3. CSRF: dùng token cho mọi form thay đổi dữ liệu

Cross-site request forgery (CSRF) lợi dụng việc trình duyệt tự gửi cookie đăng nhập. Một trang khác có thể khiến người dùng đang đăng nhập vô tình gửi yêu cầu đổi email, đổi mật khẩu hay xóa dữ liệu trên website của bạn. Cách phòng chuẩn là token ngẫu nhiên gắn với phiên, được kiểm tra ở mọi request POST, PUT, PATCH, DELETE.

Code không an toàn

// KHÔNG AN TOÀN: chỉ cần người dùng đang đăng nhập là xử lý
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    updateEmail($_SESSION['user_id'], $_POST['email']);
}

Code an toàn

// AN TOÀN: tạo token theo phiên và kiểm tra khi submit
session_start();
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

// Trong form:
// <input type="hidden" name="csrf_token" value="<?= e($_SESSION['csrf_token']) ?>">

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $token = $_POST['csrf_token'] ?? '';
    if (!hash_equals($_SESSION['csrf_token'], $token)) {
        http_response_code(403);
        exit('Yêu cầu không hợp lệ');
    }
    updateEmail($_SESSION['user_id'], $_POST['email']);
}

Dùng random_bytes() để tạo token và hash_equals() để so sánh, tránh rò rỉ thông tin qua thời gian so sánh. Kết hợp thêm cookie SameSite=Lax và không bao giờ thay đổi dữ liệu bằng request GET. Chi tiết xem OWASP CSRF Prevention Cheat Sheet.

4. Upload file không an toàn

Chức năng upload là cửa ngõ phổ biến để đưa file độc hại lên server. Rủi ro lớn nhất là file chứa mã PHP được lưu trong thư mục web và có thể được gọi qua trình duyệt. Tên file và $_FILES[...]['type'] đều do phía người gửi quyết định, nên không thể tin.

Code không an toàn

// KHÔNG AN TOÀN: tin tên file và MIME do trình duyệt gửi lên,
// lưu ngay trong thư mục public
$name = $_FILES['avatar']['name'];
if ($_FILES['avatar']['type'] === 'image/jpeg') {
    move_uploaded_file($_FILES['avatar']['tmp_name'], __DIR__ . '/uploads/' . $name);
}

Code an toàn hơn

// AN TOÀN HƠN: kiểm tra lỗi, dung lượng, MIME thật bằng finfo, đổi tên ngẫu nhiên
$file = $_FILES['avatar'] ?? null;
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png', 'image/webp' => 'webp'];

if (!$file || $file['error'] !== UPLOAD_ERR_OK || $file['size'] > 2 * 1024 * 1024) {
    http_response_code(400);
    exit('File không hợp lệ');
}

$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime  = $finfo->file($file['tmp_name']);
if (!isset($allowed[$mime])) {
    http_response_code(415);
    exit('Định dạng không được hỗ trợ');
}

$newName = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
// Thư mục lưu nằm NGOÀI web root, ví dụ /var/www/app/storage/uploads
move_uploaded_file($file['tmp_name'], '/var/www/app/storage/uploads/' . $newName);

Bốn nguyên tắc cần nhớ:

1. Kiểm tra MIME thật bằng finfo, kết hợp allowlist định dạng và giới hạn dung lượng.
2. Đổi tên file bằng chuỗi ngẫu nhiên, tự gán phần mở rộng theo MIME, không dùng tên gốc.
3. Lưu ngoài web root và trả file qua một script có kiểm tra quyền.
4. Chặn thực thi ở thư mục upload nếu buộc phải để file trong public.

# Nginx: chặn thực thi PHP trong thư mục upload (nếu buộc phải để trong public)
location ~* ^/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

# Apache (.htaccess đặt trong thư mục uploads)
<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>

Với ảnh, bạn có thể xử lý lại (resize, re-encode bằng GD hoặc Imagick) để loại bỏ dữ liệu thừa. Xem thêm OWASP File Upload Cheat Sheet.

5. LFI/RFI và path traversal

Local File Inclusion (LFI) và Remote File Inclusion (RFI) xảy ra khi tham số người dùng quyết định file nào được include hoặc require. Path traversal là biến thể với các hàm đọc file như readfile(), file_get_contents(): người dùng dùng ký tự đường dẫn để thoát khỏi thư mục dự kiến và đọc file cấu hình, khóa bí mật.

Code không an toàn

// KHÔNG AN TOÀN: include theo tham số trên URL
$page = $_GET['page'] ?? 'home';
include __DIR__ . '/pages/' . $page . '.php';

Code an toàn: allowlist

// AN TOÀN: chỉ cho phép một danh sách cố định
$pages = [
    'home'    => 'home.php',
    'about'   => 'about.php',
    'contact' => 'contact.php',
];
$key = $_GET['page'] ?? 'home';
$file = $pages[$key] ?? $pages['home'];
include __DIR__ . '/pages/' . $file;

Đọc file an toàn: realpath và kiểm tra thư mục gốc

// Tải file: chuẩn hóa đường dẫn rồi kiểm tra nó vẫn nằm trong thư mục cho phép
$baseDir = realpath('/var/www/app/storage/invoices');
$path    = realpath($baseDir . '/' . basename($_GET['file'] ?? ''));

if ($path === false || !str_starts_with($path, $baseDir . DIRECTORY_SEPARATOR)) {
    http_response_code(404);
    exit;
}
readfile($path);

Ở cấp cấu hình, giữ allow_url_include = Off (mặc định là Off và tùy chọn này đã bị đánh dấu deprecated từ PHP 7.4, theo php.net). Thêm open_basedir để giới hạn thư mục PHP được phép truy cập.

6. Command injection: escapeshellarg và hạn chế gọi shell

Các hàm exec(), system(), shell_exec(), passthru() chạy lệnh qua shell của hệ điều hành. Nếu dữ liệu người dùng lọt vào chuỗi lệnh, shell có thể hiểu nó là lệnh thêm vào. Hậu quả thường là chiếm toàn bộ quyền của tài khoản chạy PHP.

Code không an toàn

// KHÔNG AN TOÀN: đưa dữ liệu người dùng vào lệnh shell
$host = $_GET['host'];
echo shell_exec('ping -c 3 ' . $host);

Code an toàn hơn

// AN TOÀN HƠN: validate trước, sau đó escape từng tham số
$host = $_GET['host'] ?? '';
if (!filter_var($host, FILTER_VALIDATE_IP)) {
    exit('Địa chỉ IP không hợp lệ');
}
echo shell_exec('ping -c 3 ' . escapeshellarg($host));

// Tốt hơn nữa (PHP 7.4+): truyền mảng cho proc_open để KHÔNG đi qua shell
$proc = proc_open(['ping', '-c', '3', $host], [1 => ['pipe', 'w']], $pipes);
echo stream_get_contents($pipes[1]);
fclose($pipes[1]);
proc_close($proc);

Thứ tự ưu tiên: (1) dùng hàm hoặc thư viện PHP thay cho lệnh shell (ví dụ Imagick thay vì gọi convert); (2) nếu buộc phải gọi lệnh ngoài, truyền mảng cho proc_open() để không đi qua shell; (3) nếu vẫn dùng chuỗi lệnh, validate chặt rồi bọc từng tham số bằng escapeshellarg(). Trên hosting không cần các hàm này, hãy tắt chúng bằng disable_functions.

7. Insecure deserialization: tránh unserialize dữ liệu người dùng

unserialize() có thể khởi tạo đối tượng và kích hoạt các magic method như __wakeup(), __destruct(). Khi kết hợp với các lớp có sẵn trong dự án hoặc thư viện, dữ liệu do người dùng kiểm soát có thể dẫn tới đọc ghi file hoặc thực thi mã. Tài liệu chính thức của unserialize() trên php.net cảnh báo rõ: không truyền dữ liệu không tin cậy vào hàm này, kể cả khi đặt allowed_classes.

Code không an toàn

// KHÔNG AN TOÀN: unserialize dữ liệu từ cookie
$cart = unserialize($_COOKIE['cart']);

Code an toàn: dùng JSON

// AN TOÀN: dùng JSON cho dữ liệu đi qua tay người dùng
try {
    $cart = json_decode($_COOKIE['cart'] ?? '[]', true, 16, JSON_THROW_ON_ERROR);
} catch (JsonException $e) {
    $cart = [];
}
if (!is_array($cart)) {
    $cart = [];
}

Nếu buộc phải lưu dữ liệu serialize ở nơi người dùng có thể chạm tới, hãy ký bằng hash_hmac() và kiểm tra chữ ký trước khi đọc. Nhưng cách đơn giản và an toàn hơn vẫn là JSON.

8. Session và mật khẩu: password_hash, session_regenerate_id, cookie flags

Nhóm lỗi xác thực gồm lưu mật khẩu yếu, không đổi session ID sau khi đăng nhập (session fixation) và cookie phiên thiếu các cờ bảo vệ. Đây là lỗi rất phổ biến trong code PHP tự viết.

Mật khẩu: không dùng md5, sha1

// KHÔNG AN TOÀN: md5/sha1 không phù hợp để lưu mật khẩu
$hash = md5($_POST['password']);

// AN TOÀN: password_hash + password_verify
$hash = password_hash($_POST['password'], PASSWORD_DEFAULT); // lưu cột VARCHAR(255)

// Khi đăng nhập
if ($user && password_verify($_POST['password'], $user['password_hash'])) {
    if (password_needs_rehash($user['password_hash'], PASSWORD_DEFAULT)) {
        saveNewHash($user['id'], password_hash($_POST['password'], PASSWORD_DEFAULT));
    }
    session_regenerate_id(true);           // chống session fixation
    $_SESSION['user_id'] = $user['id'];
}

Theo tài liệu password_hash(), PASSWORD_DEFAULT hiện dùng bcrypt, cost mặc định tăng từ 10 lên 12 kể từ PHP 8.4. Bcrypt chỉ dùng tối đa 72 byte đầu của mật khẩu, và php.net khuyến nghị cột lưu hash dài 255 ký tự vì thuật toán mặc định có thể thay đổi. password_needs_rehash() giúp nâng cấp hash dần khi người dùng đăng nhập.

Session: cookie HttpOnly, Secure, SameSite

// Cấu hình cookie phiên trước session_start() (PHP 7.3+)
session_set_cookie_params([
    'lifetime' => 0,
    'path'     => '/',
    'secure'   => true,     // chỉ gửi qua HTTPS
    'httponly' => true,     // JavaScript không đọc được
    'samesite' => 'Lax',    // hoặc 'Strict'
]);
ini_set('session.use_strict_mode', '1');
session_start();

Gọi session_regenerate_id(true) ngay sau khi đăng nhập hoặc nâng quyền. Bật session.use_strict_mode, mà php.net mô tả là bắt buộc cho session an toàn dù mặc định đang tắt. Với website WordPress, các bước tương đương được trình bày trong bài bảo mật đăng nhập WordPress.

9. Cấu hình php.ini cho production

Nhiều sự cố không đến từ code mà từ cấu hình mặc định. Hiển thị lỗi ra màn hình làm lộ đường dẫn, tên bảng, đôi khi cả thông tin kết nối. Header X-Powered-By cho biết chính xác phiên bản PHP đang chạy. Đây đúng là nhóm A02 Security Misconfiguration và A10 Mishandling of Exceptional Conditions trong OWASP Top 10:2025.

; php.ini cho môi trường production
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log
expose_php = Off
allow_url_include = Off
; Chỉ tắt khi chắc chắn ứng dụng không cần, kiểm tra kỹ trước khi áp dụng
disable_functions = exec,passthru,shell_exec,system,proc_open,popen
open_basedir = /var/www/app/:/tmp/
file_uploads = On
upload_max_filesize = 8M
post_max_size = 10M
session.use_strict_mode = 1
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = Lax

• display_errors = Off và log_errors = On: người dùng thấy trang lỗi chung, chi tiết được ghi vào log.
• expose_php = Off: không quảng cáo phiên bản PHP.
• disable_functions: tắt các hàm chạy lệnh nếu ứng dụng không dùng. Một số plugin hoặc công cụ backup cần các hàm này, nên hãy thử trên môi trường staging trước.
• open_basedir: giới hạn PHP chỉ đọc ghi trong thư mục dự án.
• Xóa các file phpinfo() và file test còn sót trên server.

Nếu bạn tự quản lý máy chủ, hãy kết hợp với checklist bảo mật VPS Linux để siết cả lớp hệ điều hành.

10. Cập nhật phiên bản PHP được hỗ trợ

Code an toàn đến đâu cũng không bù được cho một trình thông dịch PHP có lỗ hổng đã công bố. Theo trang Supported Versions của php.net (kiểm tra tháng 10/2026), các nhánh còn được hỗ trợ là:

Khuyến nghị thực tế: dự án mới chọn PHP 8.4 hoặc 8.5; dự án đang chạy PHP 8.2 nên lên kế hoạch nâng cấp trước 31/12/2026. Ngoài nhánh, hãy chú ý cả bản vá nhỏ: với đợt cảnh báo ngày 21/10/2026, chạy PHP 8.4 nhưng chưa lên 8.4.27 vẫn nằm trong diện bị ảnh hưởng.

# Kiểm tra thư viện Composer có lỗ hổng đã công bố
composer audit

# Xem phiên bản PHP đang chạy (CLI)
php -v

Lệnh composer audit (có trong Composer CLI) giúp phát hiện thư viện có lỗ hổng đã công bố, đúng với hạng mục Software Supply Chain Failures mới của OWASP. Nếu dùng aaPanel, xem hướng dẫn cài đặt aaPanel trên VPS để biết cách cài và chuyển đổi phiên bản PHP.

11. Dùng framework như Laravel để có sẵn cơ chế bảo vệ

Viết PHP thuần đồng nghĩa bạn phải tự lo mọi lớp bảo vệ ở trên. Framework hiện đại như Laravel đã tích hợp sẵn phần lớn chúng: Eloquent và Query Builder bind tham số qua PDO, Blade tự escape với {{ }}, middleware CSRF bật mặc định cho route web (tài liệu Laravel CSRF), Hash facade dùng bcrypt hoặc argon2, validation hỗ trợ kiểm tra file upload.

// Laravel: các cơ chế bảo vệ có sẵn
User::where('email', $request->email)->first();        // binding tự động
DB::select('SELECT * FROM users WHERE id = ?', [$id]);  // raw nhưng vẫn bind

{{ $comment->body }}      {{-- Blade tự escape --}}
{!! $comment->body !!}    {{-- KHÔNG escape: chỉ dùng với nội dung đã làm sạch --}}

<form method="POST" action="/profile">
    @csrf
</form>

$request->validate(['avatar' => 'required|file|mimes:jpg,png,webp|max:2048']);
Hash::make($request->password);

Framework không làm thay mọi việc. Các điểm vẫn thường gặp lỗi: whereRaw/DB::raw ghép chuỗi, {!! !!} với dữ liệu người dùng, mass assignment do $guarded = [], để APP_DEBUG=true trên production và không cập nhật framework. Hãy xem framework là nền tảng tốt, còn thói quen lập trình PHP an toàn vẫn là của bạn.

Checklist lập trình PHP an toàn

• Mọi truy vấn dùng PDO prepared statement; tên cột và chiều sắp xếp dùng allowlist.
• Mọi dữ liệu in ra HTML đi qua htmlspecialchars(..., ENT_QUOTES, 'UTF-8') hoặc template engine có auto-escape.
• Có header Content-Security-Policy, ít nhất ở chế độ Report-Only.
• Mọi form thay đổi dữ liệu có CSRF token; không thay đổi dữ liệu bằng GET.
• Upload: kiểm MIME bằng finfo, đổi tên ngẫu nhiên, lưu ngoài web root, chặn thực thi PHP.
• Không include, require, readfile theo tham số người dùng nếu không có allowlist.
• Hạn chế gọi shell; nếu phải gọi thì escapeshellarg hoặc proc_open với mảng.
• Không unserialize dữ liệu người dùng; dùng JSON.
• Mật khẩu dùng password_hash; gọi session_regenerate_id(true) sau đăng nhập; cookie HttpOnly, Secure, SameSite.
• php.ini: display_errors=Off, expose_php=Off, allow_url_include=Off, cân nhắc disable_functions và open_basedir.
• Chạy phiên bản PHP còn hỗ trợ và luôn ở bản vá mới nhất; chạy composer audit định kỳ.
• Có backup và nhật ký để phát hiện, khôi phục khi có sự cố.

Câu hỏi thường gặp về bảo mật PHP

Lời kết

Phần lớn lỗ hổng bảo mật PHP có thể phòng tránh bằng vài thói quen nhất quán: tách dữ liệu khỏi câu lệnh, escape ở đầu ra, kiểm tra mọi thứ người dùng gửi lên, cấu hình production cẩn thận và cập nhật PHP đúng lịch. Không có cách nào giúp website miễn nhiễm hoàn toàn, nhưng áp dụng checklist trên sẽ giảm rủi ro rõ rệt.

Nếu bạn cần người rà soát code PHP, cập nhật phiên bản và theo dõi website định kỳ, có thể tham khảo dịch vụ bảo trì và quản trị website của TeamDevDesign hoặc liên hệ với chúng tôi để trao đổi.