- Nonce trong WordPress là gì?
- Khi nào cần dùng nonce?
- Form gửi dữ liệu thay đổi
- AJAX action thao tác dữ liệu
- REST API endpoints riêng
- Trang quản trị
- Khi nào không cần nonce?
- Nội dung chỉ đọc (GET requests)
- Public API không liên quan session
- Static assets (JS, CSS, images)
- Authentication bằng cơ chế khác
- Lỗi phổ biến khi dùng nonce
- Best practice cho 2025
- Dùng đúng chỗ
- Kết hợp với capability check
- Phân biệt context
- Hiển thị lỗi tử tế
- Kết luận
Nonce trong WordPress là gì?
Nonce là một chuỗi token ngẫu nhiên, gắn liền với user session và có thời gian sống (mặc định 24h). Nó được tạo bằng wp_create_nonce() và kiểm tra bằng wp_verify_nonce() hoặc check_admin_referer()/check_ajax_referer().
Ví dụ cơ bản:
// Tạo nonce để chèn vào form
$nonce = wp_create_nonce('delete_post');
// Kiểm tra khi form được submit
if ( isset($_POST['_wpnonce']) && wp_verify_nonce($_POST['_wpnonce'], 'delete_post') ) {
// Xử lý xóa post
}
Khi nào cần dùng nonce?
Form gửi dữ liệu thay đổi
Bất kỳ form nào có thao tác thay đổi dữ liệu (xóa, cập nhật, thêm mới) đều cần nonce. Ví dụ: form xóa bài viết, form chỉnh sửa thông tin profile, form upload file.
AJAX action thao tác dữ liệu
Khi tạo endpoint AJAX để thay đổi dữ liệu (xóa bình luận, like post, thêm vào playlist…), cần kèm nonce để ngăn CSRF. Ví dụ:
// JS gửi AJAX
jQuery.post(ajaxurl, {
action: 'delete_comment',
comment_id: 123,
_ajax_nonce: myData.nonce
});
// PHP xử lý
add_action('wp_ajax_delete_comment', function() {
check_ajax_referer('delete_comment');
// Xóa comment...
});
REST API endpoints riêng
Nếu viết custom REST route mà không yêu cầu cookie + capability mặc định, bạn có thể buộc client gửi nonce (ví dụ trong header X-WP-Nonce) để xác thực.
Trang quản trị
Trong admin panel, khi thực hiện các thao tác “nguy hiểm” (delete, update, import/export…), WordPress core luôn kèm nonce – bạn cũng nên làm theo.
Khi nào không cần nonce?
Nội dung chỉ đọc (GET requests)
Các request chỉ đọc dữ liệu (ví dụ hiển thị danh sách post, search, lọc nội dung) không cần nonce. Nếu bạn chèn nonce cho mọi GET request sẽ phá cache (page cache, CDN cache) vì mỗi user có nonce khác nhau.
Public API không liên quan session
Nếu endpoint của bạn là public (ai cũng xem được), ví dụ API trả về danh sách manga mới, thì không cần nonce. Chỉ cần sanitize/escape output.
Static assets (JS, CSS, images)
Các file tĩnh luôn được CDN cache, không cần và không nên gắn nonce.
Authentication bằng cơ chế khác
Nếu bạn đã dùng JWT, OAuth2 hoặc Bearer token để xác thực API, nonce là dư thừa.
Lỗi phổ biến khi dùng nonce
- Dùng nonce cho mọi thứ: dẫn đến cache miss, giảm hiệu năng.
- Không kiểm tra capability: nonce chỉ xác thực request đến từ user hợp lệ, nhưng bạn vẫn phải check quyền bằng
current_user_can(). - Nhầm lẫn nonce với mã hóa: nonce không phải encryption, chỉ là token một lần.
- Quên timeout: nonce mặc định 24h. Nếu flow cần thời gian dài hơn (ví dụ form nhiều bước), bạn phải xử lý khéo.
Best practice cho 2025
Dùng đúng chỗ
Chỉ áp dụng nonce cho hành động thay đổi dữ liệu. Đừng lạm dụng ở GET/public API.
Kết hợp với capability check
Ví dụ xóa post: vừa verify nonce vừa check current_user_can('delete_post', $post_id).
Phân biệt context
Sử dụng action string rõ ràng khi tạo nonce: wp_create_nonce('delete_post_' . $post_id) để tránh token bị tái sử dụng sai context.
Hiển thị lỗi tử tế
Nếu nonce hết hạn, hiển thị thông báo và hướng dẫn người dùng refresh. Đừng chỉ “die()” giữa trang trắng.
Kết luận
Nonce trong WordPress là lá chắn chống CSRF hiệu quả, nhưng không phải “cứ gắn vào là an toàn”. Dùng đúng chỗ, kết hợp với capability check, và không phá cache – đó là cách triển khai nonce chuẩn trong năm 2025. Nhớ rằng: bảo mật là nhiều lớp, nonce chỉ là một phần trong bức tranh lớn.
Bình luận