Bài này là decision/audit owner cho REST API WordPress. Dùng khi bạn cần quyết định route nào nên public, route nào cần authentication, route nào nên giới hạn và dependency nào sẽ bị ảnh hưởng nếu block. Nếu bạn đang triển khai custom endpoint, permission_callback, capability hoặc auth cụ thể, chuyển sang bảo mật REST API WordPress: authentication, permission_callback và endpoint.
Phạm vi của bài
Bài này trả lời câu hỏi “REST API hiện tại có exposure nào cần giới hạn, và có nên giới hạn không?”. Nó sở hữu inventory, risk review và decision keep/restrict/remove/investigate; không sở hữu coding implementation. Kết quả mong muốn là một ma trận route → owner → auth/authz → data/action → dependency → decision.
WordPress REST API cho phép ứng dụng đọc hoặc thay đổi dữ liệu qua endpoint HTTP. Việc API có thể truy cập công khai không tự động là lỗ hổng; điều quan trọng là endpoint nào public, endpoint nào cần authentication, capability nào được kiểm tra và integration nào đang phụ thuộc.
Khi nào REST API là attack surface đáng chú ý?
Khi endpoint cho phép đọc dữ liệu nhạy cảm, thay đổi nội dung, quản lý user hoặc thực hiện hành động đặc quyền, authentication và authorization phải được review kỹ. Plugin cũng có thể thêm custom route với logic riêng.
Kiểm tra authentication, authorization và endpoint
Public route không đồng nghĩa insecure
Một số dữ liệu được thiết kế để public. Không nên “tắt toàn bộ REST API” chỉ vì thấy endpoint trả JSON. Cần xác định business need, data exposure và permission callback của từng nhóm route quan trọng.
Authentication và Authorization
Authentication trả lời “ai đang gọi”, authorization trả lời “người đó có được làm việc này không”. Một endpoint có authentication nhưng kiểm tra capability sai vẫn có thể rủi ro.
Custom endpoint cần kiểm tra gì?
- Route và HTTP method.
- Permission callback.
- Capability phù hợp.
- Input validation và sanitization.
- Output có lộ dữ liệu nhạy cảm không.
- Rate/abuse behavior nếu public.
Nếu route phục vụ webhook hoặc callback từ hệ thống bên ngoài, review thêm bảo mật webhook WordPress.
Đừng audit API chỉ bằng cách mở URL trên trình duyệt
Một endpoint trả dữ liệu khi gọi bằng GET chưa đủ để đánh giá toàn bộ risk. Cần xem cả POST, PUT/PATCH, DELETE, route parameter, nonce/session hoặc credential dùng cho API, và capability check ở server-side. Điều cần đánh giá là action nào được phép với identity nào, không phải chỉ “route có mở hay không”.
Application Passwords
Với integration cần authentication, WordPress hỗ trợ Application Passwords trong các trường hợp phù hợp. Credential này phải được quản lý riêng và gắn với user có quyền tối thiểu. Xem quản trị Application Passwords WordPress.
Ma trận review endpoint
| Route | Auth model | Data/Action | Capability | Decision |
|---|---|---|---|---|
| Public read | Không yêu cầu auth | Dữ liệu public | N/A | Giữ nếu đúng business need |
| Authenticated write | Session/API credential | Tạo/sửa dữ liệu | Phải kiểm tra phù hợp | Review kỹ |
| Privileged admin action | Authenticated | Thay đổi cấu hình/user | Capability đặc quyền | Ưu tiên cao |
| Route không rõ owner | Không rõ | Không rõ | Không rõ | Investigate trước khi block |
Input validation và output exposure
Authorization đúng nhưng input validation yếu vẫn có thể tạo risk. Ngược lại, endpoint chỉ đọc dữ liệu public có thể ít rủi ro hơn nếu output phù hợp. Khi review custom route, tách rõ ba lớp: ai được gọi, input nào được chấp nhận và output nào được trả về.
Hardening và vận hành REST API
Có nên disable REST API?
Chỉ nên giới hạn khi bạn đã xác định route không cần thiết hoặc có yêu cầu bảo mật cụ thể. Disable mù có thể phá block editor, plugin, mobile app, headless frontend hoặc automation. Mọi rule nên có dependency check và rollback.
Giảm exposure theo route
Nếu một nhóm endpoint không cần public, ưu tiên control theo route, authentication hoặc capability thay vì chặn toàn bộ API. Với WAF/CDN, test false positive trước khi rollout rộng.
Inventory REST API
- Liệt kê route quan trọng từ core và plugin.
- Đánh dấu public/authenticated.
- Xác định dữ liệu/action của từng route.
- Map owner và integration.
- Review permission/capability.
- Review input/output behavior.
- Loại bỏ route/plugin không còn business need.
- Monitor API activity bất thường.
Monitoring signal nên theo dõi
- Spike request trên route nhạy cảm.
- Nhiều 401/403 bất thường.
- Write action ngoài business window.
- Service account gọi route ngoài expected scope.
- Credential hoặc user liên quan được nâng quyền.
Không nên làm gì?
- Không coi JSON response là bằng chứng vulnerability.
- Không disable toàn bộ REST API khi chưa kiểm tra dependency.
- Không dùng Administrator cho integration nếu không cần.
- Không hard-code API secret trong source công khai.
- Không bỏ qua authorization chỉ vì endpoint đã yêu cầu authentication.
Evidence pack cho REST API review
- Danh sách route quan trọng.
- Owner/integration dependency.
- Auth/authz model.
- Capability check.
- Input/output behavior.
- Decision keep/restrict/remove/investigate.
- Validation và rollback nếu có thay đổi.
Nguồn kỹ thuật
Kết luận
URL này sở hữu quyết định kiến trúc: inventory REST API, hiểu exposure và chọn keep/restrict/remove/investigate theo business need. Phần coding/auth/permission implementation được chuyển cho bài implementation riêng để tránh hai URL cùng cạnh tranh intent “bảo mật REST API”.