Cross-origin isolation thực chiến: COOP, COEP và SharedArrayBuffer

Một ứng dụng web cần SharedArrayBuffer, WebAssembly đa luồng hoặc timer có độ phân giải cao. Bạn thêm hai header COOP và COEP, kiểm tra thấy crossOriginIsolated === true — nhưng CDN ảnh, font, analytics hoặc popup đăng nhập bỗng ngừng hoạt động. Cross-origin isolation không khó ở hai dòng cấu hình; phần khó là hiểu mọi tài nguyên và cửa sổ mà trang đang tin cậy.

Bài này trình bày cách triển khai Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP) và Cross-Origin-Resource-Policy (CORP) theo từng bước: kiểm kê dependency, chọn require-corp hay credentialless, sửa CORS/CORP, kiểm thử popup, Worker, iframe và Service Worker, sau đó rollout có quan sát. Hành vi được đối chiếu với HTML Standard, Fetch Standard và tài liệu COOP trên MDN.

1. Cross-origin isolation giải quyết bài toán gì?

Trình duyệt phải giả định rằng tài liệu khác origin có thể không đáng tin. Một số API mạnh như shared memory làm tăng độ chính xác của quan sát thời gian và có thể khuếch đại các kiểu tấn công side-channel. Vì vậy trang chỉ được dùng đầy đủ các khả năng này khi nó nằm trong một môi trường được cô lập chéo origin.

Ở mức thực hành, trạng thái đó thường cần:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Hoặc thay COEP bằng:

Cross-Origin-Embedder-Policy: credentialless

COOP tách quan hệ giữa top-level document và các cửa sổ khác origin ở mức browsing context group. COEP yêu cầu tài nguyên nhúng cross-origin phải cho phép rõ ràng thông qua CORS hoặc CORP; với credentialless, request no-cors cross-origin được gửi không kèm credentials và không bắt buộc CORP theo cùng cách.

CORS, CORP, COEP và COOP không đồng nghĩa. CORS quyết định script có được đọc response cross-origin; CORP cho phép server tài nguyên giới hạn nơi response được dùng; COEP áp chính sách nhúng cho document; COOP kiểm soát quan hệ giữa các top-level window.

2. Điều kiện thành công phải được kiểm tra trong runtime

Không nên suy luận chỉ từ việc header xuất hiện trong DevTools. Kiểm tra capability tại đúng document và Worker:

console.log({
  secureContext: window.isSecureContext,
  isolated: window.crossOriginIsolated,
  sharedArrayBuffer: typeof SharedArrayBuffer,
});

Với Worker:

// worker.js
self.postMessage({
  isolated: self.crossOriginIsolated,
  sharedArrayBuffer: typeof SharedArrayBuffer,
});

Trang phải chạy trong secure context. Ngoài ra, directive Permissions-Policy: cross-origin-isolated có thể làm capability bị chặn ngay cả khi COOP/COEP có vẻ đúng. Hãy kiểm tra response cuối sau redirect, không chỉ response ban đầu.

3. Kiểm kê dependency trước khi bật enforcement

COEP thường làm lộ các dependency ngầm: ảnh không có CORS, script marketing tải qua no-cors, font CDN thiếu header, iframe thanh toán hoặc popup OAuth dựa vào window.opener. Tạo inventory theo loại request và owner:

Trong DevTools Network, thêm cột domain, initiator, mode và credentials; lọc request bị chặn. Đồng thời chạy crawler hoặc integration test qua các route quan trọng vì dependency chỉ xuất hiện sau tương tác người dùng có thể không nằm ở trang đầu.

4. Chọn require-corp hay credentialless

COEP: require-corp

Đây là lựa chọn dễ lý luận nhất: tài nguyên cross-origin phải được cho phép bằng CORS hoặc header CORP phù hợp. Ví dụ một CDN công khai có thể trả:

Cross-Origin-Resource-Policy: cross-origin

Hoặc client yêu cầu bằng CORS:

<script src="https://cdn.example.net/app.js"
        crossorigin="anonymous"></script>

và CDN trả:

Access-Control-Allow-Origin: https://app.example.com
Vary: Origin

Nếu tài nguyên không dùng credentials và thực sự công khai, Access-Control-Allow-Origin: * có thể phù hợp. Không dùng wildcard với credentialed CORS.

COEP: credentialless

Với credentialless, browser bỏ credentials khỏi request cross-origin ở mode no-cors; đổi lại tài nguyên đó không cần trả CORP để được nhúng. Cách này hữu ích khi bạn không kiểm soát server tài nguyên, nhưng nó thay đổi ngữ nghĩa: cookie, client certificate hoặc HTTP authentication sẽ không đi cùng các request đó.

Không chọn credentialless chỉ để “hết lỗi”. Hãy xác nhận tài nguyên thực sự công khai, không cá nhân hóa bằng cookie, không phụ thuộc anti-hotlink/session và trình duyệt mục tiêu hỗ trợ hành vi cần thiết. Request dùng CORS và credentials vẫn cần permission CORS đúng.

5. CORP nên đặt ở server tài nguyên, không phải đoán ở client

Cross-Origin-Resource-Policy có ba giá trị thường dùng:

• same-origin: chỉ cùng scheme, host và port; phù hợp cho response nhạy cảm.
• same-site: cho phép cùng site, nhưng ranh giới site rộng hơn origin; cân nhắc cẩn thận khi có nhiều subdomain do các đội khác quản lý.
• cross-origin: cho phép response được nhúng cross-origin; chỉ nên dùng cho asset có chủ đích công khai.

Ví dụ Nginx cho một thư mục asset công khai:

location /public-assets/ {
    add_header Cross-Origin-Resource-Policy cross-origin always;
    try_files $uri =404;
}

Không gắn cross-origin lên toàn bộ API hay response có dữ liệu người dùng. Header phải phản ánh contract của từng nhóm tài nguyên.

6. Cấu hình ở reverse proxy theo phạm vi route

Không phải toàn website đều cần shared memory. Cô lập một ứng dụng hoặc route riêng thường giảm blast radius cho OAuth, CMS, chat widget và trang marketing.

location /compute/ {
    add_header Cross-Origin-Opener-Policy "same-origin" always;
    add_header Cross-Origin-Embedder-Policy "require-corp" always;
    add_header Permissions-Policy "cross-origin-isolated=(self)" always;

    proxy_pass http://compute_app;
}

Với Caddy:

handle_path /compute/* {
    header {
        Cross-Origin-Opener-Policy "same-origin"
        Cross-Origin-Embedder-Policy "require-corp"
        Permissions-Policy "cross-origin-isolated=(self)"
    }
    reverse_proxy compute_app:8080
}

Kiểm tra cả HTML, redirect, error page và response do CDN cache. Nếu proxy chỉ thêm header cho status 200, một error document thiếu policy có thể tạo hành vi khác mong đợi. Với cache dùng chung, bảo đảm cache key và invalidation không trộn response giữa route có policy và không có policy.

7. Popup đăng nhập và thanh toán là điểm dễ vỡ nhất

COOP: same-origin có thể tách popup khác origin sang browsing context group khác, làm quan hệ window.opener bị cắt. Flow cũ dựa vào popup gọi trực tiếp hàm của opener, polling trạng thái popup.closed hoặc truy cập property có thể không còn hoạt động như trước.

Không “sửa” bằng cách tắt COOP ở mọi nơi. Các lựa chọn thiết kế gồm:

• Dùng full-page redirect và state/PKCE cho OAuth, sau đó quay lại route callback same-origin.
• Dùng protocol chính thức của nhà cung cấp thay vì truy cập DOM/callback tùy biến giữa hai window.
• Tách khu vực cần isolation sang origin riêng, để trang đăng nhập/thanh toán giữ policy phù hợp.
• Nếu cân nhắc same-origin-allow-popups, phải kiểm chứng liệu trang còn đạt cross-origin isolation hay không; đừng giả định tên directive đồng nghĩa với đủ điều kiện.

Test end-to-end trên các trình duyệt mục tiêu: popup bị chặn, người dùng hủy, timeout, redirect nhiều bước, SameSite cookie và tab đã mở sẵn.

8. Service Worker, iframe và cache cần kiểm thử riêng

Service Worker có thể phục vụ response đã cache từ trước khi policy được bật. Xóa cache trong test, tăng cache version và xác minh header của navigation response thực tế. Header bị thêm bằng JavaScript phía client là quá muộn; policy phải nằm trên HTTP response.

Với iframe, cả chuỗi document và subresource phải tương thích. Một iframe bên thứ ba không hỗ trợ COEP có thể không tải được trong document cô lập. Nếu iframe là nghiệp vụ bắt buộc và vendor không hỗ trợ, route/origin riêng thường rõ ràng hơn các ngoại lệ khó kiểm soát.

Worker script nên được phục vụ từ same-origin khi có thể. Kiểm tra MIME, redirect, CORS và policy của response cuối. Với WebAssembly đa luồng, test cả đường dẫn fallback không shared memory để ứng dụng có thể hiển thị thông báo hoặc chạy chế độ giảm tính năng thay vì crash trắng trang.

9. Rollout bằng report-only và quan sát chủ động

Trình duyệt có các biến thể report-only cho COOP/COEP, nhưng reporting support và schema có thể khác theo engine. Dùng chúng như tín hiệu bổ sung, không thay cho integration test và kiểm tra Network panel.

Cross-Origin-Opener-Policy-Report-Only: same-origin
Cross-Origin-Embedder-Policy-Report-Only: require-corp
Reporting-Endpoints: isolation="https://reports.example.com/browser"

Endpoint nhận report phải chống lạm dụng: giới hạn kích thước, rate limit, không tin field do client gửi, loại dữ liệu nhạy cảm và đặt retention. Rollout theo các bước:

1. Bật report-only trên staging và production canary.
2. Chạy luồng chính: tải trang, đăng nhập, thanh toán, upload, media, Worker và offline.
3. Sửa dependency bằng CORS/CORP hoặc self-host; không whitelist mù.
4. Bật enforcement cho một tỷ lệ traffic hoặc route hẹp.
5. Theo dõi JavaScript errors, resource load failures, auth conversion và crossOriginIsolated.
6. Mở rộng sau khi đủ thời gian quan sát và có rollback rõ ràng.

10. Bộ test tối thiểu trước production

test('compute page is cross-origin isolated', async ({ page }) => {
  await page.goto('https://app.example.com/compute/');

  const state = await page.evaluate(() => ({
    isolated: crossOriginIsolated,
    sab: typeof SharedArrayBuffer,
  }));

  expect(state.isolated).toBe(true);
  expect(state.sab).toBe('function');
});

Bên cạnh assertion capability, hãy kiểm tra:

• Không có request quan trọng ở trạng thái blocked.
• Font, ảnh, video, analytics cần thiết và error reporting vẫn hoạt động.
• Worker khởi tạo được và thực thi tác vụ shared memory.
• Login/logout, OAuth popup hoặc redirect, payment callback và deep link hoạt động.
• Trang error/maintenance giữ policy dự kiến.
• Phiên bản browser không hỗ trợ có fallback rõ ràng.

11. Chẩn đoán theo triệu chứng

12. Checklist triển khai

• Xác định API nào thực sự cần cross-origin isolation và thiết kế fallback.
• Lập inventory mọi subresource, iframe, Worker, popup và redirect.
• Chọn require-corp hoặc credentialless dựa trên contract credentials.
• Sửa CORS/CORP tại server sở hữu tài nguyên; không nới toàn site.
• Áp COOP/COEP theo route hoặc origin nhỏ nhất có thể.
• Kiểm thử runtime bằng crossOriginIsolated, không chỉ nhìn header.
• Test OAuth/payment, Service Worker, iframe và browser fallback.
• Canary, quan sát lỗi resource/auth và chuẩn bị rollback.

Kết luận

COOP và COEP không phải hai header có thể bật rồi quên. Chúng tạo một contract mới giữa document, popup, Worker và mọi server tài nguyên. Triển khai tốt bắt đầu bằng dependency inventory, chọn policy dựa trên credentials, sửa permission tại đúng origin và đo capability ở runtime. Khi giới hạn phạm vi, rollout canary và giữ fallback rõ ràng, bạn có thể dùng shared memory/WebAssembly đa luồng mà không đánh đổi độ ổn định của đăng nhập, thanh toán và tài nguyên bên thứ ba.