Kết quả cần đạt: response HTML của website có allowlist tối thiểu, được kiểm tra ở chế độ báo cáo trước khi chuyển sang chặn. Quy trình này phù hợp với người mới có quyền chỉnh web server, reverse proxy hoặc CDN; bạn cũng cần HTTPS, quyền truy cập cấu hình và danh sách sơ bộ các API, CDN, worker cùng dịch vụ bên thứ ba. Connection-Allowlist được Chrome 152 ghi nhận trong kênh ổn định từ ngày 25 tháng 8 năm 2026 và áp dụng cho các kết nối do document hoặc worker khởi tạo (theo developer.chrome.com). Tính năng này không thay thế HTTPS, CSP, xác thực hoặc việc bảo vệ mã nguồn máy chủ.
Connection-Allowlist kiểm soát điều gì?
Connection-Allowlist là HTTP response header chứa danh sách endpoint mà một context được phép liên lạc. Endpoint không khớp chính sách có thể bị trình duyệt chặn trước khi kết nối được tạo. Mục tiêu là thu hẹp các kênh liên lạc ngoài dự kiến, chẳng hạn một đoạn mã bị chèn cố gắng gửi dữ liệu đến máy chủ lạ.
Chính sách gắn với từng context. Header của document kiểm soát các kết nối do document tạo; header của worker kiểm soát context worker tương ứng. Header này không ngăn người dùng tự điều hướng, không sửa được mã độc trên máy chủ và không giải quyết các kênh phụ như suy luận qua CPU hoặc bộ nhớ (theo wicg.github.io).
Connection-Allowlist khác CSP ở đâu?
- CSP: phân loại nhiều loại tài nguyên bằng các chỉ thị như
script-src,style-src,img-srcvàconnect-src; CSP vẫn cần cho kiểm soát nội dung và giảm rủi ro XSS. - Connection-Allowlist: tập trung vào tập endpoint mà document hoặc worker được phép kết nối, thay vì chỉ phân loại theo loại tài nguyên.
- Kết hợp: hai cơ chế bổ sung cho nhau. Không nên gỡ CSP, CORS, CSRF protection, xác thực hoặc phân quyền chỉ vì đã thêm allowlist.
Connection-Allowlist không phải là cách thay thế cho firewall: firewall kiểm soát lưu lượng ở hạ tầng máy chủ, còn header này tạo một ràng buộc ở trình duyệt của người dùng.
Kiểm tra quyền truy cập và hạ tầng trước khi sửa
- Xác định lớp trả về HTML: ghi lại website, reverse proxy, CDN hoặc web server thực sự tạo response cuối cùng. Bạn cần quyền chỉnh lớp này, không chỉ quyền sửa mã nguồn ứng dụng.
- Chuẩn bị phiên SSH hoặc bảng điều khiển máy chủ: nếu dùng SSH, chạy các lệnh quản trị trong terminal của máy chủ; thay
admin@example.comvàexample.combằng thông tin thật. Không dán lệnh có quyền quản trị nếu chưa kiểm tra đường dẫn. - Kiểm tra DNS và HTTPS: tên miền phải trỏ đến đúng lớp phục vụ website, chứng chỉ phải hợp lệ, và cổng HTTPS cần được firewall cho phép. Connection-Allowlist không sửa lỗi DNS, chứng chỉ hoặc định tuyến.
- Sao lưu trước khi đổi: lưu bản sao cấu hình Nginx, Apache hoặc CDN cùng allowlist hiện tại. Ghi lại phiên bản cấu hình và cách reload để có thể khôi phục nếu website lỗi.
Lập allowlist tối thiểu
Đừng bắt đầu bằng wildcard rộng. Dùng DevTools, log ứng dụng và tài liệu tích hợp để lập bảng sau:
| Nhóm kết nối | Ví dụ | Cách quyết định |
|---|---|---|
| Cùng origin | https://example.com | Thường biểu diễn bằng token response-origin. |
| API riêng | https://api.example.com | Chỉ thêm nếu document hoặc worker thực sự gọi API này. |
| CDN | https://cdn.example.com | Đối chiếu tài nguyên và hostname thật trong response. |
| Dịch vụ bên thứ ba | Thanh toán, bản đồ, phân tích | Xác nhận luồng kết nối, redirect và loại dữ liệu được gửi trước khi cho phép. |
Ghi cả endpoint được gọi bởi Web Worker, Service Worker, WebSocket, WebRTC hoặc DNS prefetch nếu ứng dụng sử dụng chúng. Đừng tự động đưa mọi hostname xuất hiện trong log vào allowlist; endpoint lạ có thể đến từ thư viện không cần thiết hoặc mã bị chèn.
Viết header đúng cú pháp
Giá trị header là một Structured Field gồm một inner list. Token response-origin đại diện cho origin đã trả về document; các URL pattern còn lại là chuỗi tuyệt đối. Đặc tả cũng mô tả các tham số như redirects, webrtc và report-to.
Connection-Allowlist: (response-origin "https://api.example.com" "https://cdn.example.com")Ví dụ này cho phép document kết nối về origin đã cung cấp document, API và CDN được chỉ định. URL trong ví dụ chỉ là placeholder: thay example.com bằng hostname thật, giữ đúng giao thức, cổng và mẫu URL mà ứng dụng sử dụng. Không viết theo kiểu danh sách CSP phân tách bằng dấu phẩy.
Thử bằng Report-Only trước khi chặn
Report-Only giúp quan sát vi phạm mà chưa chặn kết nối. Đây là lựa chọn an toàn hơn khi ứng dụng có SDK, quảng cáo, đăng nhập liên miền hoặc worker chưa được lập danh sách đầy đủ.
Connection-Allowlist-Report-Only: (response-origin "https://api.example.com" "https://cdn.example.com")Nếu cần thu thập báo cáo, khai báo endpoint báo cáo do bạn kiểm soát:
Reporting-Endpoints: connection-errors="https://reports.example.com/connection"
Connection-Allowlist-Report-Only: (response-origin "https://api.example.com" "https://cdn.example.com"); report-to=connection-errorsThay URL báo cáo bằng endpoint thật và bảo vệ endpoint đó như một API tiếp nhận dữ liệu từ trình duyệt. Báo cáo có thể chứa URL context, kết nối vi phạm, allowlist và trạng thái enforce hoặc report; hãy hạn chế việc ghi log dữ liệu nhạy cảm.
Cấu hình tại Nginx hoặc Apache
Nginx
Thực hiện trong khối server hoặc location đang trả về HTML. Đoạn dưới là mẫu cấu hình; giữ lại các chỉ thị root, proxy và SSL hiện có của bạn:
server {
listen 443 ssl;
server_name example.com;
add_header Connection-Allowlist-Report-Only '(response-origin "https://api.example.com" "https://cdn.example.com")' always;
# Giữ các chỉ thị root, proxy_pass và SSL hiện có ở đây.
}Thay cả ba hostname mẫu bằng giá trị thật. Trong terminal SSH của máy chủ, kiểm tra cú pháp trước khi reload:
sudo nginx -t
sudo systemctl reload nginxKết quả mong đợi của lệnh đầu là syntax is ok và test is successful. Nếu kiểm tra thất bại, không reload; sửa file cấu hình rồi chạy lại sudo nginx -t. always giúp header xuất hiện trong nhiều response lỗi, nhưng CDN hoặc cache phía trước vẫn có thể loại bỏ hay ghi đè header.
Apache HTTP Server
Trong VirtualHost HTTPS hoặc cấu hình thư mục phù hợp, cần bật module headers trước khi đặt header:
Header always set Connection-Allowlist-Report-Only "(response-origin \"https://api.example.com\" \"https://cdn.example.com\")"Thực hiện trong terminal SSH của máy chủ:
sudo a2enmod headers
sudo apachectl configtest
sudo systemctl reload apache2Kết quả mong đợi là Syntax OK. Trên hệ điều hành hoặc bản phân phối dùng tên dịch vụ khác, thay apache2 bằng tên dịch vụ Apache thực tế. Nếu configtest lỗi, không reload cho đến khi sửa xong.
Xác minh response và các luồng thực tế
- Kiểm tra response cuối cùng: chạy trong terminal của máy khách hoặc máy chủ, thay URL bằng trang thật:
curl -sSI https://example.com/ | grep -iE 'connection-allowlist|reporting-endpoints'Phải thấy đúng header sau lớp CDN, proxy và redirect cuối cùng. Nếu không thấy, kiểm tra nơi đặt header, cache và quy tắc ghi đè response.
- Kiểm tra Network: mở Chrome DevTools, chọn Network, bật ghi log nếu cần, tải lại trang và quan sát request đến API, CDN, worker script và dịch vụ bên thứ ba.
- Đọc báo cáo: phân loại endpoint cần thiết, endpoint thừa và endpoint đáng ngờ. Tìm thư viện hoặc đoạn mã tạo kết nối trước khi bổ sung allowlist.
- Kiểm tra worker: xác nhận URL tải worker là URL dự kiến và các lệnh
fetch()trong worker chỉ gọi endpoint đã được phê duyệt. Kiểm tra riêng Service Worker nếu ứng dụng dùng nó. - Kiểm tra redirect: chạy đăng nhập, OAuth callback, thanh toán, tải tệp và thông báo thời gian thực. Đặc tả hiện tại mặc định chặn redirect; chỉ bật tham số
redirectssau khi lập danh sách từng chặng và đánh giá rủi ro. - Kiểm tra WebRTC: nếu có thoại hoặc video, xác minh riêng STUN/TURN. WebRTC có cơ chế endpoint khác request HTTP và mặc định hiện tại có thể bị chặn bằng chính sách.
Thấy header qua curl chỉ xác nhận response có header, không chứng minh toàn bộ ứng dụng hoạt động đúng. Chỉ coi bước chuẩn bị hoàn tất sau khi các luồng nghiệp vụ quan trọng và log máy chủ cho kết quả phù hợp.
Chuyển sang chế độ enforce
Sau khi xử lý các báo cáo hợp lệ, thay header Report-Only bằng header thực thi:
Connection-Allowlist: (response-origin "https://api.example.com" "https://cdn.example.com")Triển khai theo từng nhóm trang hoặc phiên bản ứng dụng nếu có thể. Sau khi reload web server, lặp lại kiểm tra bằng curl, DevTools, đăng nhập, thanh toán, tải tệp và hoạt động nền của worker. Nếu có nhiều chính sách, kết nối phải vượt qua tất cả chính sách tương ứng; một policy nghiêm ngặt hơn vẫn có thể chặn request dù CSP cho phép.
Lỗi thường gặp và cách xử lý
Trang vẫn kết nối được endpoint ngoài danh sách
Kiểm tra bạn đang thấy Connection-Allowlist hay chỉ thấy Connection-Allowlist-Report-Only. Sau đó kiểm tra response cuối cùng sau redirect, cache, CDN và phiên bản Chrome đang dùng.
API hợp lệ bị chặn
So sánh URL thực tế với pattern, gồm giao thức, hostname, cổng và đường dẫn. Kiểm tra cả request phát sinh từ worker, iframe và Service Worker vì mỗi context có thể có policy riêng.
Đăng nhập hoặc thanh toán bị hỏng
Kiểm tra redirect OAuth hoặc callback thanh toán trước khi mở wildcard. Lập danh sách từng chặng được tin cậy, đánh giá dữ liệu đi qua mỗi chặng rồi điều chỉnh tham số redirects hoặc kiến trúc callback.
WebRTC không hoạt động
Kiểm tra riêng STUN/TURN và tham số webrtc. Không thêm wildcard toàn cục chỉ để sửa nhanh; nếu chưa xác định được endpoint cần thiết, quay lại Report-Only trong khi điều tra.
Header bị lỗi cú pháp hoặc bị mất
Inner list cần dấu ngoặc tròn, URL pattern là chuỗi trong dấu ngoặc kép, còn response-origin là token không đặt trong dấu ngoặc kép. Chạy nginx -t hoặc apachectl configtest, sau đó kiểm tra response qua CDN thay vì chỉ kiểm tra file cấu hình nguồn.
Rollback và giới hạn bảo mật
Nếu tính năng quan trọng bị lỗi, trước tiên khôi phục cấu hình đã sao lưu. Cách rollback tối thiểu là đổi Connection-Allowlist về Connection-Allowlist-Report-Only, kiểm tra cú pháp, reload web server và xác minh lại response. Nếu lỗi nghiêm trọng, gỡ header enforce khỏi lớp trả về HTML; không xóa HTTPS, CSP, xác thực hoặc các cơ chế bảo vệ khác.
- Header bảo vệ các kết nối do context khởi tạo, không tự động chặn XSS, mã độc trên máy chủ hoặc thay đổi trái phép response header.
- Allowlist không thay thế xác thực, phân quyền, CORS, CSRF protection, CSP, kiểm tra đầu vào hoặc firewall.
- Wildcard rộng làm giảm giá trị chính sách. Ưu tiên origin và hostname cụ thể, chỉ mở cổng hoặc mẫu rộng khi có lý do được ghi nhận.
- Connection Allowlists hiện vẫn là đặc tả của Web Platform Incubator Community Group, chưa phải tiêu chuẩn W3C. Hãy kiểm tra hành vi trên các trình duyệt và phiên bản mà người dùng thực tế sử dụng trước khi coi đây là lớp bảo vệ duy nhất (theo github.com).
Checklist áp dụng
- Xác định lớp trả về HTML, quyền truy cập, DNS, HTTPS, firewall và đường khôi phục cấu hình.
- Lập danh sách endpoint của document, iframe, Web Worker và Service Worker.
- Thêm
Connection-Allowlist-Report-Onlyvới danh sách tối thiểu. - Chạy kiểm tra cấu hình, reload an toàn, xác minh response sau CDN và đọc báo cáo.
- Kiểm tra API, redirect, đăng nhập, thanh toán, tải tệp, WebRTC và hoạt động nền.
- Đổi sang
Connection-Allowlist, theo dõi lỗi và giữ bản sao cấu hình để rollback.
Nguyên tắc cốt lõi là: cho phép ít endpoint nhất có thể, quan sát bằng Report-Only trước, rồi chỉ bật enforce sau khi đã kiểm tra worker và các luồng redirect.
Nguồn tham khảo
