Security Headers cho website: header nào thực sự cần thiết?

Security Headers là các HTTP response header giúp browser áp dụng thêm ràng buộc về transport, script execution, framing, MIME sniffing, referrer và quyền sử dụng browser features. Không có một danh sách “bật tất cả là tốt”; mỗi header giải quyết một nhóm rủi ro khác nhau và có thể gây regression nếu triển khai sai.

Cách đánh giá đúng là hỏi: header này chặn threat nào, prerequisite là gì, có dependency nào bị ảnh hưởng và cách rollback ra sao?

Những Security Headers thường quan trọng nhất

1. Strict-Transport-Security (HSTS)

HSTS yêu cầu browser chỉ kết nối tới host qua HTTPS trong khoảng max-age đã công bố. Browser cũng không cho người dùng click-through lỗi certificate trên HSTS host. Header chỉ có hiệu lực khi nhận qua HTTPS. Nếu cần quy trình rollout chi tiết theo max-age, includeSubDomains và preload, xem HSTS là gì và khi nào nên bật Strict-Transport-Security.

Ví dụ:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Chỉ nên bật includeSubDomains khi tất cả subdomain cần thiết đã hỗ trợ HTTPS. Preload cần readiness cao hơn vì rollback khó hơn.

2. Content-Security-Policy (CSP)

CSP kiểm soát nguồn script, style, image, frame và nhiều resource khác. Với XSS mitigation, strict CSP dùng nonce/hash thường mạnh hơn location allowlist. MDN hiện khuyến nghị test CSP bằng Report-Only trước khi enforcement. Hướng triển khai đầy đủ nằm tại Content Security Policy là gì? Cách triển khai CSP an toàn.

Không nên copy một policy mẫu rồi enforce ngay production. CSP phải phản ánh resource graph thật của application.

3. X-Content-Type-Options

X-Content-Type-Options: nosniff yêu cầu browser tôn trọng MIME type thay vì cố đoán một số loại resource. Header này đặc biệt hữu ích khi website phục vụ user-controlled file hoặc asset qua nhiều route.

4. Frame protection

Ngày nay có thể dùng CSP frame-ancestors để kiểm soát website có được embed trong frame hay không. X-Frame-Options vẫn có giá trị tương thích trong một số môi trường cũ.

Ví dụ CSP:

Content-Security-Policy: frame-ancestors 'self'

Mục tiêu là giảm clickjacking khi attacker nhúng giao diện thật vào trang giả.

5. Referrer-Policy

Referrer-Policy kiểm soát lượng thông tin URL/referrer được gửi sang request khác. Một policy phổ biến là:

Referrer-Policy: strict-origin-when-cross-origin

Nó giúp giảm rò rỉ path/query nhạy cảm sang third-party mà vẫn giữ origin-level analytics trong nhiều trường hợp.

6. Permissions-Policy

Permissions-Policy giới hạn browser features như camera, microphone, geolocation, fullscreen hoặc payment theo origin/frame.

Chỉ deny những capability website thật sự không cần. Với application có embedded content hoặc payment/video call, policy quá chặt có thể làm hỏng chức năng.

Header nào không nên dùng như “điểm số”?

Scanner thường chấm điểm dựa trên presence của một số header. Nhưng “header có mặt” không chứng minh header có semantics đúng. Ví dụ:

HSTS có max-age=0 gần như đang tắt policy;
CSP có thể cực rộng với *, unsafe-inline hoặc allowlist quá lớn;
Permissions-Policy có thể deny feature mà app cần;
X-Frame-Options có thể conflict với yêu cầu embed hợp lệ.

Vì vậy SecureWebOps ưu tiên effective browser behavior hơn điểm scanner.

Security Headers không thay thế application security

Một website có đầy đủ header vẫn có thể có broken access control, SQL injection, SSRF, insecure file upload hoặc compromised administrator. Header là defense-in-depth ở browser/transport layer, không phải vulnerability scanner.

Đây cũng là lý do bài SSL Labs Grade tách rõ transport security khỏi application security.

Thứ tự triển khai an toàn

Inventory route, third-party resource, iframe và browser feature.
Đảm bảo HTTPS hoạt động ổn định trước HSTS.
Thêm các header ít rủi ro như nosniff và Referrer-Policy.
Thiết kế frame policy theo business need.
Rollout CSP bằng Report-Only trước enforcement.
Kiểm Permissions-Policy trên các feature thực tế.
Validation ở browser và route chính.
Monitor error, CSP report và regression.

Ví dụ baseline cho website đơn giản

Một baseline có thể gồm:

Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: frame-ancestors 'self'; object-src 'none'; base-uri 'self'

Đây chỉ là ví dụ khởi điểm, không phải cấu hình universal. CSP thực tế phải được thiết kế theo resource và threat model.

Checklist review

HTTPS và certificate ổn định trước HSTS.
Không bật includeSubDomains nếu còn subdomain HTTP.
CSP đang Report-Only hay enforce đã được ghi rõ.
Không dựa hoàn toàn vào host allowlist cho script nếu có thể triển khai strict CSP.
Frame policy không chặn embedded flow hợp lệ.
Referrer-Policy không làm mất dữ liệu business-critical ngoài dự kiến.
Permissions-Policy phản ánh feature thật sự cần dùng.
Header được kiểm trên response thực tế qua CDN/reverse proxy, không chỉ config file.

Security Headers và WordPress

WordPress có nhiều plugin/theme thêm inline script, third-party resource và admin-specific behavior, nên CSP/Permissions-Policy cần test kỹ. Bài WordPress-specific nằm tại Security Headers cho WordPress.

Với CSP chuyên sâu, xem CSP Strict vs Allowlist.

Kết luận

Security Headers tốt là những header có mục tiêu rõ, semantics đúng và đã được validation trên application thật. Không cần bật mọi header; cần chọn đúng control cho đúng threat.

Security Headers cho website: những header nào thực sự cần thiết?