Bảo mật cookie WordPress: Secure, HttpOnly và SameSite

Bảo mật cookie WordPress không bắt đầu bằng việc ép mọi cookie về cùng một bộ cờ. Trước hết cần inventory cookie, xác định owner và flow sử dụng; sau đó mới quyết định Secure, HttpOnly, SameSite, Domain, Path và lifetime. Với session/authentication cookie, mục tiêu là giảm khả năng bị gửi sai kênh, bị JavaScript đọc khi không cần, bị gửi trong cross-site request không mong muốn hoặc tồn tại lâu hơn nhu cầu vận hành.

Trong thực tế WordPress có thể có cookie từ core, plugin authentication, ecommerce, membership, analytics, SSO hoặc embedded integration. Vì vậy một policy “Strict cho tất cả” hoặc “HttpOnly cho tất cả” có thể làm hỏng login, checkout hoặc integration mà vẫn không giải quyết đúng rủi ro.

Secure, HttpOnly và SameSite thực sự kiểm soát gì?

Cookie inventory: bước bắt buộc trước khi thay đổi

Trước khi chỉnh header hoặc plugin setting, lập inventory tối thiểu cho từng cookie:

Nếu chưa biết owner hoặc flow của một cookie, trạng thái đúng là UNKNOWN — cần điều tra, không phải “set flag mạnh nhất rồi xem có lỗi không”.

Decision matrix cho từng loại cookie

Không có một giá trị SameSite đúng cho mọi site. Strict hạn chế mạnh cross-site request; Lax thường cân bằng hơn cho nhiều flow; None chỉ phù hợp khi cookie thực sự cần cross-site và phải đi cùng Secure.

Domain và Path: thu hẹp phạm vi khi có thể

Nếu không đặt Domain, cookie trở thành host-only cookie và chỉ quay lại host đã tạo nó. Đây thường là phạm vi hẹp hơn so với đặt cookie cho domain cha và toàn bộ subdomain. Chỉ mở rộng Domain khi có dependency thực sự giữa các host.

Path giúp giới hạn request path mà browser gửi cookie, nhưng không nên coi Path là cơ chế bảo mật chống truy cập trái phép. Nếu dữ liệu là secret/session nhạy cảm, authorization và application design vẫn là control chính.

Cookie lifetime phải phù hợp privilege

Cookie đại diện session đặc quyền không nên tồn tại lâu hơn nhu cầu vận hành. Review cùng session invalidation, password reset, MFA change và privilege change: khi account mất quyền hoặc incident xảy ra, session cũ có được revoke không?

Với account quản trị, cookie/session control nên đi cùng quản lý session WordPress, MFA/2FA WordPress và least privilege.

Header examples: chỉ là mẫu, không copy mù vào production

Set-Cookie: session_id=<value>; Path=/; Secure; HttpOnly; SameSite=Lax
Set-Cookie: cross_site_token=<value>; Path=/; Secure; HttpOnly; SameSite=None

Ví dụ trên chỉ minh họa cách thuộc tính xuất hiện trong Set-Cookie. Tên cookie, Domain, Path, lifetime và SameSite phải theo flow thật của WordPress/plugin/integration. Không nên chỉnh trực tiếp response header nếu cookie do plugin/SSO/provider quản lý mà chưa biết nguồn tạo.

Browser verification: kiểm chứng thay vì chỉ nhìn config

1. Mở DevTools → Network và thực hiện flow tạo cookie: login, checkout hoặc SSO.
2. Chọn response liên quan và kiểm tra header Set-Cookie.
3. Mở Application/Storage → Cookies; ghi Secure, HttpOnly, SameSite, Domain, Path và expiry.
4. Test login/logout, remember-me, admin, password reset và privilege flow.
5. Nếu có ecommerce/SSO/embedded integration, test cả cross-site flow thực tế.
6. Kiểm tra cookie có bị gửi tới subdomain/path rộng hơn nhu cầu không.
7. Ghi lại before/after để rollback được nếu thay đổi phá business flow.

Cookie Review Record mẫu

Đây là worksheet để ghi kết quả kiểm tra thật; không phải trạng thái mặc định của website.

review_id: COOKIE-YYYY-NNN
cookie_name: ...
owner: core|plugin|sso|ecommerce|custom
purpose: ...
domain: ...
path: ...
secure: yes|no
httponly: yes|no
samesite: Strict|Lax|None|unset
expires_or_max_age: ...
javascript_dependency: yes|no|unknown
cross_site_dependency: yes|no|unknown
privilege_level: public|user|admin
change_required: yes|no|investigate
validation_flows:
  - login: PASS|FAIL
  - logout: PASS|FAIL
  - admin: PASS|FAIL
  - checkout: N/A|PASS|FAIL
  - sso: N/A|PASS|FAIL
rollback_ref: ...
evidence_ref: ...

PASS/FAIL cho cookie hardening

• PASS: cookie có owner và purpose rõ; Secure/HttpOnly/SameSite phù hợp flow; Domain/Path không rộng hơn cần thiết; lifetime phù hợp privilege; các flow quan trọng đã test.
• FAIL: cookie session nhạy cảm thiếu control cần thiết, Domain quá rộng không có lý do, SameSite=None nhưng thiếu Secure, hoặc thay đổi security flag làm hỏng login/SSO/checkout.
• UNKNOWN: không xác định được owner, JavaScript dependency hoặc cross-site dependency. UNKNOWN phải được điều tra trước khi enforcement.

Rollback khi thay đổi cookie policy

Rollback không nên là “xóa tất cả flag”. Trước khi change, lưu cấu hình/version hiện tại và danh sách flow phải hoạt động. Nếu rollout làm hỏng authentication hoặc integration quan trọng, quay về policy trước, xác định cookie owner/flow gây lỗi rồi điều chỉnh có mục tiêu.

Với thay đổi có blast radius lớn, nên rollout theo pilot: account nội bộ hoặc staging → một nhóm route/flow → production rộng hơn, thay vì đổi nhiều cookie cùng lúc.

Cookie flags không thay thế CSRF/XSS defense

SameSite là defense-in-depth cho một số cross-site attack; HttpOnly giảm khả năng script đọc cookie nhưng không loại bỏ XSS. Ứng dụng vẫn cần permission check, nonce/CSRF control, sanitize/escape và Content Security Policy phù hợp. Cookie security là một phần trong hardening WordPress tổng thể, không phải control độc lập.

Nguồn kỹ thuật

• MDN — Secure cookie configuration
• MDN — Set-Cookie

Kết luận

Cookie hardening tốt không phải là càng nhiều flag càng tốt. Quy trình đúng là inventory → xác định owner/flow → chọn policy tối thiểu cần thiết → test browser/business flow → rollout có rollback. Khi một cookie không rõ owner hoặc dependency, hãy giữ trạng thái UNKNOWN và điều tra trước khi enforcement.