Bài này là implementation owner cho bảo mật REST API WordPress. Dùng khi bạn cần triển khai authentication, permission_callback, capability check và kiểm soát endpoint theo use case. Nếu bạn chưa biết có nên giới hạn route nào, route nào đang public hay dependency nào sẽ bị ảnh hưởng, hãy bắt đầu ở audit REST API WordPress: route và exposure.
Phạm vi của bài
Bài này trả lời câu hỏi “custom endpoint hoặc authenticated endpoint phải được triển khai thế nào để auth/authz đúng?”. Nó không sở hữu quyết định kiến trúc keep/restrict/remove trên toàn API. Kết quả mong muốn là endpoint có auth model rõ, permission/capability đúng, credential phù hợp và dependency được smoke-test.
Bảo mật REST API WordPress không đồng nghĩa với việc tắt toàn bộ /wp-json/. REST API là thành phần quan trọng của WordPress hiện đại; cách an toàn hơn là quản lý authentication, permission callback, capability và exposure của từng endpoint theo đúng use case. Đây là một lớp trong hardening WordPress tổng thể, nơi API exposure cần được kiểm soát cùng credential, quyền và monitoring.
REST API có thể public hoặc authenticated
Một số endpoint được thiết kế để đọc dữ liệu public, trong khi thao tác chỉnh sửa hoặc dữ liệu nhạy cảm cần authentication và permission phù hợp. Không nên suy luận rằng mọi response JSON public đều là lỗ hổng.
Kiểm soát REST API theo endpoint và quyền
Authentication phổ biến
| Phương thức | Use case |
|---|---|
| Cookie + nonce | Request từ wp-admin hoặc cùng origin |
| Application Passwords | External app/script qua HTTPS |
| Custom auth plugin | Khi kiến trúc yêu cầu cơ chế khác |
WordPress khuyến nghị Application Passwords cho external REST access thay vì gửi mật khẩu chính của user. Xem Application Passwords WordPress.
Permission callback là lớp bắt buộc cho custom endpoint
Khi đăng ký custom REST route, cần có permission_callback để kiểm tra user có capability phù hợp trước khi callback xử lý request. Với endpoint thật sự public có thể dùng callback public có chủ đích; với endpoint nhạy cảm cần kiểm tra capability như current_user_can().
Đừng chỉ chặn toàn bộ REST API
Block toàn bộ REST API có thể làm hỏng block editor, plugin, integration hoặc front-end app. Trước khi hạn chế, inventory endpoint đang dùng, owner, client và business dependency. Nếu cần giảm exposure, ưu tiên hạn chế endpoint hoặc action cụ thể thay vì blanket deny không có evidence.
Checklist implementation
- Xác định route, method và owner.
- Xác định endpoint public hay authenticated.
- Chọn auth model phù hợp.
- Viết/kiểm tra
permission_callback. - Map capability với business action.
- Validate/sanitize input.
- Review output exposure.
- Test action hợp lệ và action bị từ chối.
- Smoke-test integration phụ thuộc.
- Monitor 401/403 và write action bất thường sau rollout.
Dữ liệu user và enumeration
Việc một endpoint trả dữ liệu public không tự động đồng nghĩa compromise. Nếu site có yêu cầu privacy hoặc giảm metadata exposure, cần đánh giá theo route cụ thể, theme/plugin dependency và risk thực tế thay vì dùng rule “ẩn mọi thứ”.
REST API và XML-RPC
Hai cơ chế này khác nhau về thiết kế và dependency. Quyết định hạn chế XML-RPC không nên được áp dụng máy móc cho REST API. Xem bảo mật XML-RPC WordPress.
PASS/FAIL implementation
| Check | PASS | FAIL |
|---|---|---|
| Auth | Đúng identity model | Dùng credential không phù hợp |
| Authorization | Permission/capability khớp action | Authenticated user làm được action dư quyền |
| Input | Validation/sanitization phù hợp | Trust input trực tiếp |
| Output | Chỉ trả dữ liệu cần thiết | Lộ dữ liệu ngoài scope |
| Dependency | Integration smoke-test PASS | Block làm hỏng workflow |
Nguồn kỹ thuật
Kết luận
Bảo mật REST API ở URL này là implementation: auth, permission_callback, capability, input/output và integration test. Quyết định “có nên giới hạn route nào” thuộc audit/decision owner riêng, giúp hai bài phục vụ hai task khác nhau thay vì cạnh tranh cùng intent.