Tại WordCamp Europe 2026 vừa qua, Maciek Palmowski đã công bố kết quả một thử nghiệm khá sốc: ông chạy penetration test chống lại nhiều nhà cung cấp WordPress hosting tự quảng cáo là “secure hosting”, và phần lớn các lỗ hổng đặc thù WordPress vẫn lọt qua tầng phòng thủ của họ. Dịch nghĩa ra tiếng Việt thực dụng: cái dòng chữ “secure hosting” trên landing page gần như không có giá trị chứng minh gì cả.
Mình từng tư vấn cho không ít bạn chọn host, và câu hỏi mình hay nhận nhất là “host nào bảo mật tốt?”. Câu trả lời thật sự là: đừng tin lời quảng cáo, hãy tự kiểm tra. Trong bài này, mình sẽ hướng dẫn bạn kiểm tra hosting WordPress của mình từ A đến Z bằng các lệnh cụ thể, đúng tinh thần mà Maciek đã làm trong nghiên cứu của ông.
Secure hosting là gì và tại sao marketing thường không khớp thực tế?

Secure hosting là dịch vụ hosting có các cơ chế kỹ thuật thật sự chặn được tấn công phổ biến nhắm vào WordPress: brute force login, khai thác plugin lỗi, malicious upload qua XML-RPC, hay PHP exploit. Vấn đề nằm ở chỗ chữ “secure” trên trang bán hàng không phải tiêu chuẩn đo được. Maciek đã pen-test nhiều host và thấy hầu hết lỗ hổng đặc thù WordPress-level vẫn đi xuyên qua, vì host thường chỉ chống được tấn công tầng mạng, không phải tầng ứng dụng.
Kiểm tra HTTP security headers có đúng chuẩn chưa?
Đây là phép thử nhanh nhất, mất 30 giây. Headers bảo mật cho biết host và cấu hình server của bạn có quan tâm đến bảo mật hay không:
curl -sI https://domain-cua-ban.com | grep -iE "strict-transport|x-frame|x-content-type|referrer|content-security|permissions-policy"Kết quả lý tưởng bạn cần thấy:
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: ...Nếu output trống trơn hoặc chỉ ra mỗi Server: Apache thì host đó về cơ bản chưa làm gì ở tầng HTTP. Với Nginx bạn tự thêm được trong nginx.conf, còn nếu dùng host quản lý mà thiếu headers này, đó là tín hiệu đáng lo.
Chấm điểm cấu hình TLS của hosting ra sao?
Chứng chỉ SSL miễn phí giờ là tiêu chuẩn tối thiểu, nhưng cấu hình TLS mới quyết định độ an toàn. Chạy thử:
testssl.sh --quiet https://domain-cua-ban.comhoặc dùng công cụ trực tuyến SSL Labs. Mình muốn thấy tối thiểu xếp hạng A, TLS 1.2 trở lên, và không còn TLS 1.0/1.1. Trong các bài test của Maciek, không ít host “secure” vẫn bật các protocol lỗi thời vì ngại phá tương thích khách hàng cũ.
Host có chặn được tấn công đặc thù WordPress không?
Đây là phần quan trọng nhất và cũng là chỗ hầu hết host trượt. Ba phép thử mình hay làm:
1. XML-RPC còn mở nguyên xi không:
curl -s -X POST https://domain-cua-ban.com/xmlrpc.php \
-d "<methodCall><methodName>system.listMethods</methodName></methodCall>" | head -5Nếu server trả về danh sách method thay vì 403, host chưa chặn brute-force amplification qua XML-RPC.
2. wp-login.php bị spam bao nhiêu lần chưa bị rate limit:
for i in {1..10}; do curl -s -o /dev/null -w "%{http_code}\n" \
-X POST https://domain-cua-ban.com/wp-login.php; done10 lần liên tiếp đều trả 200 nghĩa là không có rate limiting. Một host thật sự quan tâm sẽ trả 429 sau vài lần thử.
3. Upload file PHP độc hại có bị chặn không:
Tạo file test.php nội dung <?php echo "test"; ?> rồi upload qua Media Library. Nếu host thi hành được file đó (truy cập URL thấy chữ test), nghĩa là thư mục uploads không có quy tắc chặn PHP execution — đúng kiểu lỗ hổng mà backdoor WPForms Lite hồi giữa năm đã khai thác, vụ việc mình có bài phân tích chi tiết tại đây.
Quyền file và user isolation của host xử lý ra sao?
Trên shared hosting, một site dính malware có thể lây sang site khác nếu user isolation kém. Nếu bạn có SSH, kiểm tra:
# Ai là chủ sở hữu file WordPress
ls -la /home/user/public_html/wp-config.php
# PHP chạy dưới user nào
php -r "echo exec('whoami');"
# hoặc upload file info.php chứa: <?php echo shell_exec('whoami'); ?>Nếu PHP chạy dưới user chung như www-data hay nobody trên shared host, file của bạn và hàng xóm có thể “nhìn thấy nhau”. Host nghiêm túc dùng LiteSpeed/lsapi hoặc PHP-FPM theo từng user, kèm open_basedir.
Nên làm gì khi host trượt bài kiểm tra?
Nếu host của bạn trượt 2-3 phép thử trên, mình đề xuất lộ trình ba bước. Một, gửi ticket yêu cầu host bật security headers, rate limit wp-login và chặn PHP execution trong uploads — nhiều host làm được ngay nếu khách hỏi. Hai, tự phủ sóng bằng WAF ở tầng DNS như Cloudflare (miễn phí) để chặn brute force và bot độc. Ba, nếu host từ chối cải thiện, đó là lúc đổi nhà — định hướng chọn host mới mình từng chia sẻ trong loạt bài chuẩn bị nâng cấp WordPress 7.1 mà bạn đọc có thể xem tại đây.
Câu hỏi thường gặp
Kiểm tra bảo mật hosting WordPress mất bao lâu?
Toàn bộ các phép thử trong bài chỉ mất khoảng 15-20 phút nếu bạn có SSH. Riêng kiểm tra headers và TLS làm được trong 1 phút bằng curl và trình duyệt, còn các phép thử XML-RPC, rate limit và upload cần thao tác cẩn thận hơn một chút.
Host đắt tiền có phải luôn bảo mật hơn không?
Không hẳn. Nghiên cứu của Maciek cho thấy giá cả và lời quảng cáo không tương quan với kết quả pen-test. Một host 5 đô/tháng cấu hình chuẩn có thể an toàn hơn host 30 đô/tháng lơ là cấu hình, nên phép đo duy nhất đáng tin là kết quả kiểm tra thực tế của chính bạn.
Dùng plugin security có thay được host tốt không?
Plugin như Wordfence hay Solid Security giúp rất nhiều ở tầng ứng dụng, nhưng chúng chạy bằng chính tài nguyên của site và không chặn được lỗ hổng tầng server như quyền file sai hay thiếu isolation giữa các user. Câu trả lời đúng là dùng cả hai, không thay thế nhau.
