Fetch Metadata bảo vệ origin: ma trận Sec-Fetch từ Chromium thật

Fetch Metadata bảo vệ origin là cách máy chủ đọc nhóm header Sec-Fetch do trình duyệt gắn vào request để biết request đó đến từ đâu, rồi từ chối những request không nên có. Khi một trang hay API trả 403 khó hiểu, đọc ba header này thường cho câu trả lời nhanh hơn đọc cấu hình CORS. ProxyVN dựng ba origin trên máy, mở chúng bằng trình duyệt Chromium 152 thật, ghi log từng request và đối chiếu với một chính sách chặn mẫu.

Fetch Metadata bảo vệ origin: mục tiêu và phạm vi không lặp

Phần này chốt bài toán, đầu ra và những điều bài không làm.

Bài toán cần giải

Một đội vận hành gắn chính sách Fetch Metadata cho ứng dụng nội bộ. Vài ngày sau, một trang đối tác nhúng ảnh từ ứng dụng thì ảnh vỡ, một widget gọi API thì nhận 403. Người chẩn đoán xem cấu hình CORS và thấy mọi thứ đúng. Lỗi nằm ở một tầng khác, và bài này chỉ cách nhận ra tầng đó.

Đầu ra nghiệm thu

Đầu ra là một ma trận gồm điều hướng, tài nguyên nhúng và lệnh fetch, mỗi ô ghi Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Origin, mã trạng thái và lý do chính sách. Ma trận được đo trên ba quan hệ: cùng origin, cùng site khác origin, khác site. Kèm theo là kết luận chính sách nào đã chặn, chính sách nào đã cho qua.

Ranh giới với CORS và CSP

Bài không giải thích lại CORS. CORS quyết định JavaScript có đọc được response hay không, sau khi máy chủ đã xử lý request. Fetch Metadata cho máy chủ quyết định có xử lý request hay không. CSP là chính sách của trang gọi, không phải của máy chủ được gọi. Ba thứ này hay bị nhầm, phần sáu sẽ tách chúng.

Không hướng dẫn giả header

Bài không hướng dẫn tự gắn hay sửa header Sec-Fetch để vượt chính sách của một website. Chính sách này bảo vệ người dùng trình duyệt khỏi trang độc hại. Mục tiêu của bài là giúp chủ origin và người chẩn đoán hiểu request bị từ chối vì sao.

Giới hạn của lab

Ba origin là máy chủ http.server tự viết chạy trên 127.0.0.1. Trình duyệt là Chromium 152.0.7977.167 nằm trong ứng dụng Claude cho Windows. Header Sec-Fetch là do trình duyệt thật sinh ra, không phải do lab tự gắn. Ngoài trình duyệt, lab có thêm hai lượt gọi bằng requests 2.34.2 và curl để làm đối chứng.

Ai nên đọc

Người viết API và ứng dụng web muốn chặn CSRF và rò rỉ chéo site ở phía máy chủ. Người chẩn đoán 403 từ trình duyệt mà không thấy trong log CORS. Người vận hành reverse proxy hoặc WAF đứng trước origin và muốn biết có nên chuyển tiếp các header này.

Giải thích Sec-Fetch-Site/Mode/Dest cho người chẩn đoán request bị origin từ chối nhờ Fetch Metadata bảo vệ origin

Phần này tóm tắt đặc tả, chỉ giữ những ý cần khi đọc log.

Bốn header của đặc tả

Đặc tả Fetch Metadata Request Headers của W3C định nghĩa bốn header: Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site và Sec-Fetch-User. Ba header đầu là một token theo Structured Fields. Header cuối là một boolean, chỉ có ở điều hướng do người dùng kích hoạt.

Sec-Fetch-Site

Sec-Fetch-Site cho biết quan hệ giữa nơi khởi tạo request và nơi nhận. Giá trị là same-origin, same-site, cross-site hoặc none. Giá trị none dành cho request do người dùng trực tiếp gây ra, như gõ địa chỉ hoặc mở dấu trang. Đây là header quan trọng nhất cho chính sách chặn.

Sec-Fetch-Mode

Sec-Fetch-Mode là mode của request theo chuẩn Fetch: navigate, cors, no-cors, same-origin hoặc websocket. Thẻ img và script không có thuộc tính crossorigin đi với no-cors. Lệnh fetch mặc định đi với cors. Điều hướng trang và khung đi với navigate.

Sec-Fetch-Dest

Sec-Fetch-Dest cho biết response sẽ được dùng vào đâu: document, iframe, image, script, style, empty và nhiều giá trị khác. Lệnh fetch có dest là empty. Giá trị này giúp máy chủ biết một request ảnh thật sự được dùng làm ảnh, không phải được đọc bằng JavaScript.

Sec-Fetch-User

Sec-Fetch-User chỉ xuất hiện với điều hướng có kích hoạt của người dùng, mang giá trị ?1. Trong lab, lượt gõ địa chỉ vào thanh địa chỉ có Sec-Fetch-User: ?1. Lượt điều hướng bằng lệnh click() trong JavaScript không có header này, vì đó không phải cú nhấp của người dùng.

Chỉ gửi tới URL đáng tin cậy

Đặc tả yêu cầu trình duyệt chỉ gắn các header này khi URL đích là potentially trustworthy. Hiểu đơn giản là HTTPS, hoặc localhost và 127.0.0.1. Một origin HTTP thường trên mạng sẽ không nhận được Sec-Fetch. Lab chạy được trên HTTP vì mọi origin đều nằm ở loopback.

Tiền tố Sec- chặn JavaScript sửa

Đặc tả mục 4.2 giải thích tiền tố Sec- biến các header này thành tên bị cấm, JavaScript trên trang không đặt hay sửa được. Một trang độc hại không thể bảo trình duyệt gửi Sec-Fetch-Site: same-origin. Đó là lý do máy chủ có thể tin giá trị khi request đến từ trình duyệt.

Each of the headers defined in this document is prefixed with Sec-, which makes them all forbidden. (W3C Fetch Metadata, mục 4.2)

Không tin được với client khác

Sự tin cậy trên chỉ đúng với trình duyệt. Một chương trình bất kỳ có thể gửi bất kỳ header nào. Fetch Metadata vì vậy không phải là cơ chế xác thực hay chống bot. Nó là lớp phòng vệ cho người dùng trình duyệt trước trang khác site, không phải hàng rào cho mọi client.

Chuyển hướng giữ giá trị xấu nhất

Đặc tả nói nếu chuỗi chuyển hướng đi qua một site khác, request cuối vẫn mang cross-site dù quay lại đúng site ban đầu. Khi chẩn đoán, một request mang cross-site đôi khi không đến thẳng từ trang khác mà đi qua một dịch vụ rút gọn hay đăng nhập ở site khác.

Tạo navigation, fetch và subresource trên origin lab để kiểm Fetch Metadata bảo vệ origin

Phần này mô tả ba origin, trang thử và cách mở chúng bằng trình duyệt.

Ba origin trên một máy

Origin A là http://localhost:9881, ứng dụng cần bảo vệ. Origin B là http://127.0.0.1:9882, đóng vai trang khác site. Origin C là http://localhost:9883, cùng host localhost với A nhưng khác cổng. Lab còn mở C dưới tên http://app.localhost:9883 để xem trình duyệt xếp quan hệ ra sao.

Hai nhánh đường dẫn trên A

Mọi đường dẫn bắt đầu bằng /p/ trên A áp chính sách chặn và trả 403 khi chính sách từ chối. Nhánh /np/ chỉ ghi log, không chặn, để so sánh. Riêng /p/public là ngoại lệ trong chính sách, đại diện cho endpoint cố ý mở cho site khác.

Trang thử trên B và C

Trang /attack trên B và C nhúng sáu loại request tới A: một link điều hướng, thẻ img, thẻ link stylesheet, thẻ script, một iframe, và một form POST gửi vào iframe ẩn. Sau đó trang chạy bốn lệnh fetch: cors tới /p/api, no-cors tới /p/api, cors tới /np/api và cors tới /p/public.

<img src="http://localhost:9881/p/img.png?from=9882">
<link rel=stylesheet href="http://localhost:9881/p/style.css?from=9882">
<script src="http://localhost:9881/p/app.js?from=9882"></script>
<iframe src="http://localhost:9881/p/frame?from=9882"></iframe>
<form method=POST action="http://localhost:9881/p/transfer?from=9882" target=sink>

Trang tự gọi trên A

Trang /p/home trên A nhúng một ảnh, một script và chạy một lệnh fetch tới chính A. Đây là ca cùng origin, ca mà mọi chính sách hợp lý đều phải cho qua. Nếu ca này bị chặn, chính sách viết sai từ gốc.

Mở bằng trình duyệt thật

Lab mở /p/home bằng cách gõ địa chỉ, rồi mở /attack trên B, trên localhost:9883 và trên app.localhost:9883. Trên trang B, lab gọi click() vào link để tạo điều hướng sang A. Phiên bản trình duyệt được đọc bằng navigator.userAgentData và ghi vào kết quả.

Đối chứng ngoài trình duyệt

Lab gọi thêm /p/api bằng requests và curl. Hai client này không gửi header Sec-Fetch nào. Kết quả của chúng cho thấy chính sách xử lý ra sao với request không mang metadata, trường hợp rất phổ biến khi API có cả client trình duyệt lẫn client máy.

Không dùng cache

Mọi response đều có Cache-Control: no-store. Nếu không, lần tải thứ hai của cùng ảnh có thể đến từ cache và không chạm máy chủ, làm thiếu dòng trong log. Với chính sách thật, response phụ thuộc Sec-Fetch cần thêm header Vary, như đặc tả mục 5.1 khuyên.

Lưu log dạng JSON Lines

Mỗi request ghi một dòng: cổng, method, URL, bốn header Sec-Fetch, Origin, mã trạng thái và lý do chính sách. Ma trận trong bài được in thẳng từ tệp log này. Không có dòng nào được gõ tay.

Ghi Sec-Fetch-Site, Mode và Dest thực tế để chẩn đoán Fetch Metadata bảo vệ origin

Đây là log thật từ Chromium 152 sau khi chạy hết các trang thử.

Ca cùng origin

Lượt gõ địa chỉ /p/home có Site none, Mode navigate, Dest document, User ?1. Ảnh, script và fetch trên trang đó đều mang Site same-origin. Ảnh và script có Mode no-cors, fetch có Mode cors và Dest empty. Lệnh fetch cùng origin không có header Origin vì là GET.

Ca khác site từ 127.0.0.1

Ba origin trên một máy

Mọi request từ trang B tới A mang Site cross-site. Ảnh có Dest image, stylesheet có Dest style, script có Dest script, cả ba đều no-cors. Iframe có Mode navigate, Dest iframe. Fetch cors có Origin http://127.0.0.1:9882, fetch no-cors không có Origin.

Ca cùng site khác cổng

Từ http://localhost:9883, mọi request tới A mang Site same-site. Cổng khác nhau làm hai trang khác origin, nhưng site chỉ xét scheme và tên miền đăng ký được, không xét cổng. Chính sách mẫu cho cùng site qua, nên mọi request từ trang này đều nhận 200.

Ca app.localhost

Từ http://app.localhost:9883, Chromium gắn Site cross-site cho mọi request tới localhost:9881. Trình duyệt không coi app.localhost và localhost là cùng site. Đây là kết quả đo, không phải suy luận từ tên miền. Ai dùng các tên phụ của localhost để giả lập môi trường nhiều site cần biết điều này.

Điều hướng bằng click()

Lượt click() vào link trên B tạo request GET /p/home với Site cross-site, Mode navigate, Dest document và không có Sec-Fetch-User. So với lượt gõ địa chỉ, hai lượt điều hướng tới cùng trang khác nhau ở Site và User. Máy chủ phân biệt được người dùng tự mở trang với trang khác đẩy người dùng tới.

Form POST khác site

Form POST từ B gửi vào iframe ẩn mang Site cross-site, Mode navigate, Dest iframe, Origin http://127.0.0.1:9882. Đây là dạng CSRF cổ điển. Chính sách mẫu chặn nó vì method là POST. Cùng form đó từ trang cùng site đi qua và nhận 200.

Client không phải trình duyệt

Lượt gọi bằng requests và curl không mang header Sec-Fetch nào, cũng không có Origin. Chính sách mẫu cho cả hai qua với lý do không có Sec-Fetch-Site. Đây là hành vi cố ý của mẫu chính sách, giải thích ở phần sau.

Bảng giá trị gặp trong lab

Bảng giá trị Sec-Fetch

Bảng: Bảng giá trị gặp trong lab

Loại request	Site (từ B)	Mode	Dest
Gõ địa chỉ	none	navigate	document
Link click()	cross-site	navigate	document
img	cross-site	no-cors	image
link stylesheet	cross-site	no-cors	style
script	cross-site	no-cors	script
iframe	cross-site	navigate	iframe
form POST vào iframe	cross-site	navigate	iframe
fetch cors	cross-site	cors	empty
fetch no-cors	cross-site	no-cors	empty

Đối chiếu quyết định policy của origin với context request trong Fetch Metadata bảo vệ origin

Phần này đặt chính sách mẫu cạnh log để xem nó chặn đúng và chặn thừa ở đâu.

Chính sách mẫu

Lab dùng chính sách Resource Isolation phổ biến. Cho qua nếu không có Sec-Fetch-Site. Cho qua nếu Site là same-origin, same-site hoặc none. Cho qua điều hướng GET không phải object hay embed. Mọi trường hợp còn lại trả 403.

def policy(h, method):
    site = h.get("Sec-Fetch-Site")
    if site is None:
        return True, "khong co Sec-Fetch-Site"
    if site in ("same-origin", "same-site", "none"):
        return True, f"site={site}"
    if (h.get("Sec-Fetch-Mode") == "navigate" and method == "GET"
            and h.get("Sec-Fetch-Dest") not in ("object", "embed")):
        return True, "dieu huong GET cross-site"
    return False, f"cross-site {h.get('Sec-Fetch-Mode')}/{h.get('Sec-Fetch-Dest')} {method}"

Kết quả từ trang khác site

Từ B, chính sách chặn ảnh, stylesheet, script, fetch cors, fetch no-cors và form POST, đều trả 403. Nó cho qua iframe và link điều hướng vì đó là điều hướng GET. Hai endpoint /np/api và /p/public trả 200 như thiết kế.

Kết quả từ trang cùng site

Từ localhost:9883, mọi request đều qua, kể cả form POST. Nếu ứng dụng muốn chặn cả site cùng tên miền, ví dụ vì các tên phụ do nhiều đội quản lý, chính sách phải bỏ same-site khỏi danh sách cho qua. Lựa chọn này cần quyết định có ý thức, không để mặc định.

Ma trận kết luận

Ma trận quyết định

Bảng: Ma trận kết luận

Nguồn	img/css/js	iframe	fetch cors /p/api	form POST	Quyết định chính
Cùng origin A	200	không thử	200	không thử	same-origin cho qua
localhost:9883	200	200	200	200	same-site cho qua
127.0.0.1:9882	403	200	403	403	cross-site bị chặn trừ điều hướng GET
app.localhost:9883	403	200	403	403	trình duyệt xếp là cross-site
requests, curl	không áp	không áp	200	không áp	không có header, cho qua

Chặn đúng

Form POST khác site bị chặn trước khi tới logic ứng dụng. Fetch no-cors khác site cũng bị chặn, điều mà CORS không làm được, vì no-cors vẫn gửi request và máy chủ vẫn xử lý. Ảnh và script bị chặn giúp giảm rò rỉ thông tin qua kích thước và thời gian tải.

Chặn thừa

Nếu ứng dụng có ảnh hay tệp tĩnh cố ý cho site khác nhúng, chính sách mẫu làm vỡ chúng. Đó là đúng loại lỗi trong bài toán đầu bài. Cách xử lý là đưa đường dẫn đó vào danh sách ngoại lệ như /p/public, không nới cả chính sách.

Iframe vẫn qua

Chính sách mẫu cho iframe khác site qua vì đó là điều hướng. Như vậy Fetch Metadata không chống clickjacking. Ứng dụng cần thêm frame-ancestors trong CSP hoặc X-Frame-Options nếu không muốn bị nhúng. Đây là ví dụ cho thấy không chính sách nào thay được tất cả.

Request không có header được cho qua

Mẫu chính sách cho qua request thiếu Sec-Fetch-Site để không làm hỏng trình duyệt cũ và client máy. Hệ quả là chính sách chỉ có tác dụng với trình duyệt hiện đại. Đây là giới hạn thiết kế, không phải lỗ hổng cần vá bằng cách đòi mọi client gửi header.

Header Vary

Response của A thay đổi theo Sec-Fetch, nên lab gắn Vary: Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest. Nếu có cache dùng chung đứng trước origin mà thiếu Vary, một response 403 có thể bị lưu và trả cho cả request cùng origin.

Phân biệt lỗi policy này với CORS và không hướng dẫn giả header né chặn Fetch Metadata bảo vệ origin

Phần này giúp người chẩn đoán nhận ra lỗi đang thuộc tầng nào.

Dấu hiệu của lỗi Fetch Metadata

Request tới máy chủ, máy chủ trả 403 ngay, log có Sec-Fetch-Site là cross-site. Trong lab, fetch cors từ B nhận status 403, type cors. JavaScript đọc được mã 403 vì A vẫn trả header Access-Control-Allow-Origin. Mã trạng thái là của chính sách, không phải của CORS.

Dấu hiệu của lỗi CORS

Với lỗi CORS, máy chủ thường trả 200 nhưng thiếu header cho phép. Trình duyệt chặn JavaScript đọc response và báo lỗi mạng. Log máy chủ có request với mã 200. Nếu thấy 200 ở máy chủ mà trình duyệt báo lỗi, đó là CORS. Nếu thấy 403 ở máy chủ kèm cross-site, đó là chính sách.

no-cors không phải đường vòng

Trong lab, fetch no-cors trả type opaque, status 0 ở phía JavaScript, cả khi máy chủ trả 403. Trang gọi không biết request có bị chặn hay không. Với chính sách Fetch Metadata, máy chủ đã từ chối xử lý, nên no-cors không giúp trang khác site làm được gì thêm.

Ranh giới với bài CORS

Bài CORS và proxy trên ProxyVN có ghi Sec-Fetch-Site và Mode trong log để giải thích CORS. Bài này đi ngược chiều: lấy Sec-Fetch làm đầu vào cho quyết định chặn của máy chủ. Đọc cả hai sẽ thấy đầy đủ cả hai phía của cùng một request.

Không phải chuyện của proxy chuyển tiếp

Proxy chuyển tiếp chỉ chuyển header trình duyệt đã gắn. Đổi IP không đổi quan hệ site giữa trang gọi và máy chủ. Nếu một trang khác site bị chặn, đổi proxy không thay đổi kết quả. Câu hỏi đúng là chính sách có nên cho nguồn đó qua hay không.

Vì sao không giả header

Trình duyệt không cho trang web sửa Sec-Fetch, nên kẻ tấn công trên web không giả được. Client máy thì gửi được bất kỳ header nào, nhưng client máy cũng không mang cookie của người dùng. Giả header từ client máy không giúp được việc chính đáng nào. Việc chính đáng là xin chủ origin thêm ngoại lệ hoặc dùng API dành cho client máy.

Reverse proxy làm mất header

Một rủi ro thật nằm ở phía chủ origin. Nếu reverse proxy hoặc WAF đứng trước ứng dụng bỏ các header Sec-Fetch, chính sách mẫu sẽ thấy mọi request là thiếu header và cho qua hết. Lab chưa dựng ca này, nhưng logic của chính sách cho thấy rõ hệ quả.

Kiểm nhanh khi gặp 403

Mở công cụ nhà phát triển, xem tab Network, chọn request bị 403 và đọc ba header Sec-Fetch trong phần Request Headers. So với bảng ở phần bốn. Nếu Site là cross-site và loại request không thuộc nhóm được cho qua, nguyên nhân là chính sách của máy chủ.

Đầu ra nghiệm thu Fetch Metadata bảo vệ origin: ma trận navigation subresource fetch cùng origin, log và kết luận chính sách

Phần này gom đầu ra thành bản ghi có thể lưu cùng cấu hình chính sách.

Tệp đầu ra

Lab sinh log.jsonl và matrix.txt. Mỗi dòng ma trận ghi cổng, method, URL, Site, Mode, Dest, User, Origin, mã trạng thái và lý do. Ghi kèm phiên bản trình duyệt Chromium 152.0.7977.167 và hệ điều hành Windows, vì giá trị header có thể khác giữa các phiên bản.

Danh sách kiểm tra

Danh sách nghiệm thu

• Ca cùng origin đi qua chính sách với mọi loại request.
• Ca khác site có đủ điều hướng, tài nguyên nhúng, fetch cors, fetch no-cors và form POST.
• Ca cùng site khác origin được đo riêng, không suy từ tên miền.
• Có ca client không phải trình duyệt.
• Endpoint cố ý mở cho site khác có trong danh sách ngoại lệ.
• Response phụ thuộc Sec-Fetch có Vary.
• Chính sách chống nhúng khung được xử lý riêng bằng frame-ancestors.

Những gì lab chưa chạy

Chưa thử Firefox và Safari. Chưa thử HTTPS trên tên miền thật. Chưa thử Service Worker, WebSocket, tải trước bằng link rel=preload và điều hướng qua chuỗi chuyển hướng. Chưa dựng reverse proxy hay WAF thật đứng trước origin. Lượt điều hướng có Sec-Fetch-User chỉ đo bằng cách gõ địa chỉ.

Câu kết luận được phép viết

Câu được phép viết là: trên Chromium 152, request nhúng và fetch từ trang khác site mang cross-site và bị chính sách mẫu trả 403, còn điều hướng GET và iframe đi qua. Câu không được phép viết là: Fetch Metadata chặn mọi truy cập trái phép. Lab có hai client máy đi qua chính sách.

Triển khai và vận hành Fetch Metadata bảo vệ origin

Phần này chuyển kết quả lab thành các bước triển khai cho chủ origin.

Bắt đầu bằng chế độ chỉ ghi log

Nhánh /np/ của lab là mô hình nên dùng trước. Ghi lại quyết định chính sách cho mọi request trong vài tuần nhưng không chặn. Sau đó lọc những request sẽ bị chặn, xem có phải lưu lượng chính đáng không, rồi mới bật chặn.

Danh sách ngoại lệ có chủ

Mỗi ngoại lệ như /p/public nên có tên người chịu trách nhiệm và lý do. Ảnh cho đối tác nhúng, tệp tĩnh dùng chung, endpoint SSO là các ứng viên thường gặp. Ngoại lệ không có chủ sẽ lớn dần và làm chính sách mất tác dụng.

Đặt ở tầng gần ứng dụng

Chính sách cần thấy header gốc từ trình duyệt. Đặt nó trong ứng dụng hoặc ở reverse proxy đầu tiên nhận request. Kiểm mọi tầng phía trước có chuyển nguyên Sec-Fetch không, bằng cách ghi log header ở ứng dụng trong lúc mở trang bằng trình duyệt.

Kết hợp với lớp khác

Fetch Metadata đứng cùng cookie SameSite, token CSRF, frame-ancestors và CORS. Lab cho thấy nó chặn được no-cors và ảnh khác site, điều CORS không làm. Nó không chặn iframe và client máy, điều các lớp khác phải lo.

Thông báo lỗi đủ ý

Response 403 của chính sách nên có thân lỗi ngắn ghi rõ lý do, như lab ghi blocked by resource isolation policy. Người chẩn đoán phân biệt được lỗi chính sách với lỗi quyền truy cập hay lỗi xác thực. Không cần ghi giá trị header vào thân lỗi.

Kiểm lại sau mỗi bản trình duyệt lớn

Giá trị Sec-Fetch do trình duyệt quyết định và có thể đổi. Giữ trang /attack của lab như một bài test, chạy lại sau mỗi bản trình duyệt lớn và so ma trận mới với ma trận cũ. Dòng nào đổi thì xem lại chính sách.

Đo tỷ lệ chặn theo nguồn

Trong giai đoạn ghi log, gom các request sẽ bị chặn theo giá trị Origin hoặc Referer, theo Dest và theo đường dẫn. Một nguồn lạ chiếm tỷ lệ lớn thường là tích hợp cũ mà không ai ghi lại. Một nguồn nhỏ rải rác nhiều đường dẫn thường là trang độc hại hoặc tiện ích trình duyệt. Hai nhóm này cần cách xử lý khác nhau.

Viết chính sách thành bảng cấu hình

Thay vì viết điều kiện rải rác trong mã, đặt chính sách vào một bảng: nhóm đường dẫn, các giá trị Site được phép, các Mode được phép và method được phép. Bảng dễ đọc khi duyệt thay đổi và dễ so sánh với ma trận nghiệm thu. Mỗi lần thêm ngoại lệ, bảng cho thấy ngay phạm vi ảnh hưởng.

Tiện ích trình duyệt

Đặc tả mục 4.4 khuyên trình duyệt gắn cross-site cho request của tiện ích không có quyền với URL, và same-origin cho tiện ích có quyền. Nếu người dùng than phiền tiện ích hợp lệ bị chặn, đó là loại lưu lượng cần ghi nhận riêng. Lab chưa thử tiện ích nào.

Giá trị mới trong tương lai

Danh sách giá trị của Dest đã thêm dần qua các bản trình duyệt. Chính sách nên xử lý giá trị lạ theo hướng an toàn và ghi log, thay vì gặp lỗi. Hàm của lab chỉ so sánh với một vài giá trị cụ thể, nên giá trị lạ đi theo nhánh mặc định là chặn khi khác site.

Proxy ở đâu trong luồng

Với đội thu thập dữ liệu, chính sách này không phải thứ cần né mà là tín hiệu để dùng đúng kênh, như API công khai hay nguồn xuất dữ liệu. Khi cần IP tại Việt Nam cho các tác vụ hợp lệ, anh em có thể mua proxy tại trang chủ ProxyVN. Vai trò của proxy có ở bài Web Scraping proxy là gì, cách ghi chuỗi cấu hình có ở bài định dạng proxy.

Fetch Metadata bảo vệ origin: câu hỏi thường gặp

Các câu dưới đây gom những điểm hay bị hỏi.

Fetch Metadata có thay CORS không?

Không. CORS quyết định trang được đọc response hay không. Fetch Metadata giúp máy chủ quyết định có xử lý request hay không.

Vì sao request từ curl không bị chặn?

curl không gửi Sec-Fetch-Site. Chính sách mẫu cho request thiếu header qua để không làm hỏng client máy và trình duyệt cũ.

Khác cổng có phải khác site không?

Không. Trong lab, localhost:9883 gọi localhost:9881 mang same-site. Khác cổng chỉ làm khác origin.

app.localhost có cùng site với localhost không?

Trong lab, Chromium 152 xếp là cross-site. Kết quả này cần đo lại trên trình duyệt và phiên bản anh em dùng.

Fetch Metadata có chống được clickjacking không?

Không với chính sách mẫu. Iframe khác site đi qua vì là điều hướng GET. Cần frame-ancestors hoặc X-Frame-Options.

Header có gửi qua HTTP thường không?

Chỉ tới URL đáng tin cậy như HTTPS hoặc loopback. Origin HTTP thường trên mạng sẽ không nhận được.

Có nên tự thêm Sec-Fetch vào request của crawler không?

Không. Header này mô tả ngữ cảnh trình duyệt. Thêm nó vào client máy không phản ánh sự thật và không giải quyết việc chính đáng nào.

Fetch Metadata bảo vệ origin và những điều cần nhớ

Fetch Metadata bảo vệ origin cho máy chủ đọc nơi khởi tạo request từ header trình duyệt tự gắn, rồi chặn request nhúng, fetch và form khác site trước khi tới logic ứng dụng. Lab trên Chromium 152 cho thấy điều hướng GET, iframe và client máy vẫn đi qua. Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khuyên anh em bắt đầu bằng chế độ ghi log rồi mới bật chặn với Fetch Metadata bảo vệ origin.