Bài này là implementation owner cho một Application Password dùng với REST API/integration. Dùng khi bạn cần tạo credential riêng, chọn user/role, bắt buộc HTTPS, test endpoint, revoke/rotation và PASS/FAIL. Nếu bạn đang quản trị nhiều credential theo owner, inventory và lifecycle dài hạn, chuyển sang Application Passwords WordPress: quản trị credential, rotation và revoke.
Phạm vi của bài
Bài này trả lời câu hỏi “tôi triển khai một Application Password cho integration thế nào cho an toàn?”. Nó không sở hữu credential governance ở quy mô toàn site. Kết quả mong muốn là một integration hoạt động qua HTTPS với identity đủ quyền nhưng không dư quyền, credential tách riêng và revoke test thành công.
Application Passwords trong WordPress là credential dành cho ứng dụng và script truy cập API thay vì dùng mật khẩu chính của user. Chúng không dùng để đăng nhập tương tác vào wp-login.php, có thể tạo riêng cho từng integration và thu hồi độc lập. Đây là một phần của hardening WordPress tổng thể, nơi credential kỹ thuật cần đi cùng least privilege, HTTPS và lifecycle revoke/rotation.
Khi nào nên dùng?
| Use case | Phù hợp? |
|---|---|
| REST API integration | Có, nếu dùng HTTPS và scope user phù hợp |
| Script bảo trì/deploy | Có, nếu có owner và rotation |
| Desktop/mobile client | Có thể |
| Đăng nhập wp-admin bằng trình duyệt | Không |
Triển khai Application Password an toàn
1. Dùng credential riêng cho từng integration
Không chia sẻ một credential cho nhiều tool. Credential riêng giúp revoke độc lập, giảm blast radius và giữ attribution rõ khi có sự cố.
2. Chọn user có quyền tối thiểu
Application Password thừa hưởng quyền của user tương ứng. Nếu integration chỉ cần một số action, không dùng Administrator chỉ vì tiện. Xem Least Privilege WordPress.
3. Chỉ gửi credential qua HTTPS
Không truyền Application Password qua HTTP và không ghi secret vào log, source public hoặc ticket không bảo vệ. Với deployment tự động, lưu secret trong cơ chế quản lý bí mật phù hợp.
4. Test đúng endpoint và business action
Không chỉ kiểm tra “API trả 200”. Hãy xác minh đúng route/action mà integration cần, đồng thời kiểm tra các action ngoài scope bị từ chối theo authorization hiện có.
5. Revoke/rotation phải được test
Sau khi integration hoạt động, tạo credential thử nghiệm, revoke và xác minh request bị từ chối; sau đó tạo credential mới và kiểm tra integration phục hồi bình thường. Đây là acceptance test quan trọng hơn việc chỉ ghi policy “sẽ rotate định kỳ”.
Application Password không thay MFA cho wp-admin
Đây là credential cho API/application. Với login tương tác, dùng password mạnh và MFA/2FA. Xem MFA/2FA cho WordPress.
Checklist PASS/FAIL
| Check | PASS | FAIL |
|---|---|---|
| Ownership | Credential gắn với app/owner rõ | Credential không rõ nguồn |
| Transport | Chỉ dùng HTTPS | Gửi credential qua HTTP |
| Privilege | User có quyền tối thiểu | Dùng Administrator vì tiện |
| Isolation | Mỗi integration có credential riêng | Dùng chung credential |
| Lifecycle | Revoke test và rotation có smoke test | Credential bỏ quên lâu dài |
Liên quan đến REST API
Application Password thường đi cùng REST API, nhưng authentication không thay authorization. Endpoint vẫn phải kiểm tra permission/capability phù hợp. Xem bảo mật REST API WordPress cho phần implementation endpoint.
Nguồn kỹ thuật
Kết luận
Triển khai Application Password an toàn là một task implementation cụ thể: credential riêng, HTTPS, least privilege, endpoint test và revoke/rotation test. Khi cần inventory và quản trị credential lâu dài trên toàn hệ thống, chuyển sang lifecycle owner riêng thay vì dồn hai intent vào cùng URL.