Trang này trình bày một số phương pháp hay nhất để thiết lập Referrer-Policy và sử dụng referrer trong các yêu cầu đến.
Tóm tắt
- Việc rò rỉ thông tin ngoài dự kiến giữa các nguồn gốc sẽ gây tổn hại đến quyền riêng tư của người dùng web. Chính sách giới thiệu bảo vệ có thể giúp bạn giải quyết vấn đề này.
- Cân nhắc việc đặt chính sách liên kết giới thiệu là
strict-origin-when-cross-origin
. Phương thức này giúp duy trì hầu hết tính hữu ích của liên kết giới thiệu, đồng thời giảm thiểu nguy cơ rò rỉ dữ liệu giữa các nguồn gốc. - Không sử dụng trình giới thiệu để bảo vệ khỏi hành vi giả mạo yêu cầu trên nhiều trang web (CSRF). Thay vào đó, hãy sử dụng mã thông báo CSRF và các tiêu đề khác làm một lớp bảo mật bổ sung.
Kiến thức cơ bản về Referrer và Referrer-Policy
Yêu cầu HTTP có thể bao gồm tiêu đề Referer
không bắt buộc, cho biết nguồn gốc hoặc URL trang web mà yêu cầu được thực hiện. Tiêu đề Referrer-Policy
xác định dữ liệu nào được cung cấp trong tiêu đề Referer
.
Trong ví dụ sau, tiêu đề Referer
bao gồm URL đầy đủ của trang trên site-one
mà yêu cầu được thực hiện.
Tiêu đề Referer
có thể xuất hiện trong nhiều loại yêu cầu:
- Yêu cầu điều hướng, khi người dùng nhấp vào một đường liên kết.
- Yêu cầu tài nguyên phụ, khi trình duyệt yêu cầu hình ảnh, iframe, tập lệnh và các tài nguyên khác mà trang cần.
Đối với các thành phần điều hướng và iframe, bạn cũng có thể truy cập dữ liệu này bằng JavaScript thông qua document.referrer
.
Bạn có thể học hỏi nhiều điều từ các giá trị Referer
. Ví dụ: một dịch vụ phân tích có thể sử dụng các giá trị này để xác định rằng 50% số khách truy cập trên site-two.example
đến từ social-network.example
. Tuy nhiên, khi URL đầy đủ, bao gồm cả đường dẫn và chuỗi truy vấn, được gửi trong Referer
trên nhiều nguồn gốc, thì điều này có thể gây nguy hiểm cho quyền riêng tư của người dùng và tạo ra rủi ro bảo mật:
URL từ #1 đến #5 chứa thông tin riêng tư và đôi khi là thông tin nhạy cảm hoặc thông tin nhận dạng. Việc rò rỉ các thông tin này một cách thầm lặng giữa các nguồn gốc có thể làm tổn hại đến quyền riêng tư của người dùng web.
URL số 6 là URL chức năng. Nếu bất kỳ ai khác ngoài người dùng dự định nhận được mã này, thì kẻ có ý đồ xấu có thể kiểm soát tài khoản của người dùng này.
Để hạn chế dữ liệu liên kết được cung cấp cho các yêu cầu từ trang web của bạn, bạn có thể đặt chính sách liên kết.
Có những chính sách nào và chúng khác nhau như thế nào?
Bạn có thể chọn một trong 8 chính sách. Tuỳ thuộc vào chính sách, dữ liệu có sẵn từ tiêu đề Referer
(và document.referrer
) có thể là:
- Không có dữ liệu (không có tiêu đề
Referer
) - Chỉ nguồn gốc
- URL đầy đủ: nguồn gốc, đường dẫn và chuỗi truy vấn
Một số chính sách được thiết kế để hoạt động theo cách khác nhau tuỳ thuộc vào ngữ cảnh: yêu cầu trên nhiều nguồn gốc hay trên cùng một nguồn gốc, liệu đích đến của yêu cầu có an toàn như nguồn gốc hay không, hoặc cả hai. Điều này rất hữu ích để giới hạn lượng thông tin được chia sẻ giữa các nguồn gốc hoặc đến các nguồn gốc kém an toàn hơn, trong khi vẫn duy trì sự phong phú của liên kết giới thiệu trong trang web của riêng bạn.
Bảng sau đây cho biết cách các chính sách liên kết giới hạn dữ liệu URL có sẵn từ tiêu đề Liên kết giới thiệu và document.referrer
:
Phạm vi áp dụng chính sách | Tên chính sách | Trình giới thiệu: Không có dữ liệu | Trình giới thiệu: Chỉ nguồn gốc | URL giới thiệu: URL đầy đủ |
---|---|---|---|---|
Không xem xét ngữ cảnh yêu cầu | no-referrer |
kiểm tra | ||
origin |
kiểm tra | |||
unsafe-url |
kiểm tra | |||
Tập trung vào bảo mật | strict-origin |
Yêu cầu từ HTTPS sang HTTP | Yêu cầu từ HTTPS sang HTTPS hoặc HTTP sang HTTP |
|
no-referrer-when-downgrade |
Yêu cầu từ HTTPS sang HTTP | Yêu cầu từ HTTPS sang HTTPS hoặc HTTP sang HTTP |
||
Tập trung vào quyền riêng tư | origin-when-cross-origin |
Yêu cầu trên nhiều nguồn gốc | Yêu cầu cùng nguồn gốc | |
same-origin |
Yêu cầu trên nhiều nguồn gốc | Yêu cầu cùng nguồn gốc | ||
Tập trung vào quyền riêng tư và bảo mật | strict-origin-when-cross-origin |
Yêu cầu từ HTTPS sang HTTP | Yêu cầu trên nhiều nguồn gốc từ HTTPS sang HTTPS hoặc HTTP sang HTTP |
Yêu cầu cùng nguồn gốc |
MDN cung cấp danh sách đầy đủ các chính sách và ví dụ về hành vi.
Dưới đây là một số điều cần lưu ý khi đặt chính sách liên kết giới thiệu:
- Tất cả các chính sách xem xét giao thức (HTTPS so với HTTP) (
strict-origin
,no-referrer-when-downgrade
vàstrict-origin-when-cross-origin
) đều xử lý các yêu cầu từ một nguồn gốc HTTP đến một nguồn gốc HTTP khác giống như các yêu cầu từ một nguồn gốc HTTPS đến một nguồn gốc HTTPS khác, mặc dù HTTP kém an toàn hơn. Lý do là đối với các chính sách này, điều quan trọng là liệu có xảy ra hoạt động hạ cấp bảo mật hay không; tức là liệu yêu cầu có thể hiển thị dữ liệu từ một nguồn gốc được mã hoá cho một nguồn gốc không được mã hoá hay không, như trong các yêu cầu HTTPS → HTTP. Yêu cầu HTTP → HTTP hoàn toàn không được mã hoá, vì vậy không có trường hợp hạ cấp. - Nếu một yêu cầu là cùng nguồn gốc, thì điều này có nghĩa là giao thức (HTTPS hoặc HTTP) giống nhau, vì vậy, không có việc hạ cấp bảo mật nào.
Chính sách liên kết giới thiệu mặc định trong trình duyệt
Tính đến tháng 10 năm 2021
Nếu bạn không đặt chính sách liên kết giới thiệu, trình duyệt sẽ sử dụng chính sách mặc định.
Trình duyệt | Referrer-Policy mặc định / Hành vi |
---|---|
Chrome |
Mặc định là strict-origin-when-cross-origin .
|
Firefox |
Mặc định là strict-origin-when-cross-origin .Kể từ phiên bản 93, đối với người dùng Chế độ bảo vệ nghiêm ngặt khỏi tính năng theo dõi và Chế độ duyệt web riêng tư, các chính sách giới hạn ít nghiêm ngặt hơn về liên kết giới thiệu no-referrer-when-downgrade ,
origin-when-cross-origin và unsafe-url sẽ
bị bỏ qua đối với các yêu cầu trên nhiều trang web, nghĩa là liên kết giới thiệu luôn bị cắt bớt
đối với các yêu cầu trên nhiều trang web, bất kể chính sách của trang web.
|
Edge |
Mặc định là strict-origin-when-cross-origin .
|
Safari |
Giá trị mặc định tương tự như strict-origin-when-cross-origin , nhưng có một số điểm khác biệt cụ thể. Hãy xem bài viết
Ngăn chặn tính năng Theo dõi biện pháp ngăn chặn theo dõi để biết thông tin chi tiết.
|
Các phương pháp hay nhất để thiết lập chính sách liên kết giới thiệu
Có nhiều cách để đặt chính sách liên kết giới thiệu cho trang web của bạn:
- Dưới dạng tiêu đề HTTP
- Trong HTML
- Từ JavaScript trên mỗi yêu cầu
Bạn có thể đặt các chính sách khác nhau cho các trang, yêu cầu hoặc phần tử khác nhau.
Tiêu đề HTTP và phần tử meta đều ở cấp trang. Thứ tự ưu tiên để xác định chính sách có hiệu lực của một phần tử như sau:
- Chính sách ở cấp phần tử
- Chính sách cấp trang
- Mặc định của trình duyệt
Ví dụ:
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />
Hình ảnh được yêu cầu bằng chính sách no-referrer-when-downgrade
và tất cả các yêu cầu tài nguyên phụ khác từ trang này tuân theo chính sách strict-origin-when-cross-origin
.
Làm cách nào để xem chính sách về đường liên kết giới thiệu?
securityheaders.com rất hữu ích để xác định chính sách mà một trang web hoặc trang cụ thể đang sử dụng.
Bạn cũng có thể sử dụng các công cụ dành cho nhà phát triển trong Chrome, Edge hoặc Firefox để xem chính sách liên kết được sử dụng cho một yêu cầu cụ thể. Tại thời điểm viết bài này, Safari không hiển thị tiêu đề Referrer-Policy
, nhưng hiển thị Referer
đã được gửi.
Bạn nên đặt chính sách nào cho trang web của mình?
Bạn nên đặt rõ ràng một chính sách tăng cường quyền riêng tư như strict-origin-when-cross-origin
(hoặc nghiêm ngặt hơn).
Tại sao phải "rõ ràng"?
Nếu bạn không đặt chính sách liên kết giới thiệu, thì chính sách mặc định của trình duyệt sẽ được sử dụng. Trên thực tế, các trang web thường sử dụng chính sách mặc định của trình duyệt. Tuy nhiên, đây không phải là cách lý tưởng vì:
- Các trình duyệt khác nhau có các chính sách mặc định khác nhau, vì vậy, nếu bạn dựa vào các chính sách mặc định của trình duyệt, trang web của bạn sẽ không hoạt động như dự kiến trên các trình duyệt.
- Các trình duyệt đang áp dụng các giá trị mặc định nghiêm ngặt hơn như
strict-origin-when-cross-origin
và các cơ chế như cắt bớt tệp giới thiệu cho các yêu cầu trên nhiều nguồn gốc. Việc chọn rõ ràng một chính sách tăng cường quyền riêng tư trước khi các chế độ mặc định của trình duyệt thay đổi sẽ giúp bạn kiểm soát và chạy các thử nghiệm khi bạn thấy phù hợp.
Tại sao là strict-origin-when-cross-origin
(hoặc nghiêm ngặt hơn)?
Bạn cần có một chính sách an toàn, bảo vệ quyền riêng tư và hữu ích. "Có ích" có nghĩa là gì phụ thuộc vào những gì bạn muốn từ người giới thiệu:
- Bảo mật: nếu trang web của bạn sử dụng HTTPS (nếu không, hãy ưu tiên sử dụng), bạn không muốn URL của trang web bị rò rỉ trong các yêu cầu không phải HTTPS. Vì bất kỳ ai trên mạng đều có thể xem các thông tin này, nên việc rò rỉ sẽ khiến người dùng của bạn phải đối mặt với các cuộc tấn công giả mạo. Các chính sách
no-referrer-when-downgrade
,strict-origin-when-cross-origin
,no-referrer
vàstrict-origin
sẽ giải quyết vấn đề này. - Tăng cường quyền riêng tư: đối với yêu cầu trên nhiều nguồn gốc,
no-referrer-when-downgrade
chia sẻ URL đầy đủ, điều này có thể gây ra vấn đề về quyền riêng tư.strict-origin-when-cross-origin
vàstrict-origin
chỉ chia sẻ nguồn gốc vàno-referrer
không chia sẻ gì cả. Điều này giúp bạn có các tuỳ chọnstrict-origin-when-cross-origin
,strict-origin
vàno-referrer
để tăng cường quyền riêng tư. - Hữu ích:
no-referrer
vàstrict-origin
không bao giờ chia sẻ URL đầy đủ, ngay cả đối với các yêu cầu cùng nguồn gốc. Nếu bạn cần URL đầy đủ,strict-origin-when-cross-origin
là lựa chọn tốt hơn.
Tất cả những điều này có nghĩa là strict-origin-when-cross-origin
thường là một lựa chọn hợp lý.
Ví dụ: Thiết lập chính sách strict-origin-when-cross-origin
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
Hoặc phía máy chủ, ví dụ như trong Express:
const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));
Điều gì sẽ xảy ra nếu strict-origin-when-cross-origin
(hoặc nghiêm ngặt hơn) không đáp ứng được tất cả trường hợp sử dụng của bạn?
Trong trường hợp này, hãy áp dụng phương pháp tăng dần: đặt chính sách bảo vệ như strict-origin-when-cross-origin
cho trang web của bạn và nếu cần, hãy đặt chính sách nới lỏng hơn cho các yêu cầu hoặc phần tử HTML cụ thể.
Ví dụ: chính sách cấp phần tử
index.html
:
<head>
<!-- document-level policy: strict-origin-when-cross-origin -->
<meta name="referrer" content="strict-origin-when-cross-origin" />
<head>
<body>
<!-- policy on this <a> element: no-referrer-when-downgrade -->
<a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
<body></body>
</body>
</head>
</head>
Safari/WebKit có thể giới hạn document.referrer
hoặc tiêu đề Referer
cho các yêu cầu trên nhiều trang web.
Xem thông tin chi tiết.
Ví dụ: chính sách ở cấp yêu cầu
script.js
:
fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});
Bạn nên cân nhắc những điều gì khác?
Chính sách của bạn phải phụ thuộc vào trang web và trường hợp sử dụng, do bạn, nhóm của bạn và công ty của bạn xác định. Nếu một số URL chứa dữ liệu nhận dạng hoặc dữ liệu nhạy cảm, hãy đặt chính sách bảo vệ.
Các phương pháp hay nhất cho các yêu cầu đến
Dưới đây là một số nguyên tắc về việc cần làm nếu trang web của bạn sử dụng URL giới thiệu của các yêu cầu đến.
Bảo vệ dữ liệu của người dùng
Referer
có thể chứa dữ liệu riêng tư, cá nhân hoặc dữ liệu nhận dạng, vì vậy, hãy đảm bảo bạn xử lý dữ liệu đó theo cách phù hợp.
Đường liên kết giới thiệu đến có thể thay đổi {referer-can-change}
Việc sử dụng tệp giới thiệu từ các yêu cầu gốc chéo đến có một số hạn chế:
- Nếu không có quyền kiểm soát việc triển khai trình phát hành yêu cầu, bạn không thể đưa ra giả định về tiêu đề
Referer
(vàdocument.referrer
) mà bạn nhận được. Trình phát hành yêu cầu có thể quyết định chuyển sang chính sáchno-referrer
bất cứ lúc nào hoặc nói chung là chuyển sang chính sách nghiêm ngặt hơn so với chính sách mà họ từng sử dụng. Điều này có nghĩa là bạn nhận được ít dữ liệu hơn từReferer
so với trước đây. - Theo mặc định, các trình duyệt ngày càng sử dụng Referrer-Policy
strict-origin-when-cross-origin
. Điều này có nghĩa là giờ đây, bạn có thể chỉ nhận được nguồn gốc thay vì URL đầy đủ của đường liên kết giới thiệu trong các yêu cầu từ nhiều nguồn sắp tới, nếu trang web gửi không đặt chính sách. - Các trình duyệt có thể thay đổi cách quản lý
Referer
. Ví dụ: một số nhà phát triển trình duyệt có thể quyết định luôn cắt bớt các liên kết giới thiệu đến nguồn gốc trong các yêu cầu tài nguyên phụ trên nhiều nguồn gốc để bảo vệ quyền riêng tư của người dùng. - Tiêu đề
Referer
(vàdocument.referrer
) có thể chứa nhiều dữ liệu hơn mức bạn cần. Ví dụ: đối số này có thể có URL đầy đủ khi bạn chỉ muốn biết liệu yêu cầu có phải là yêu cầu nhiều nguồn gốc hay không.
Các phương án thay thế cho Referer
Bạn có thể cần cân nhắc các giải pháp thay thế nếu:
- Một tính năng thiết yếu của trang web sử dụng URL giới thiệu của các yêu cầu qua nhiều nguồn gốc sắp tới.
- Trang web của bạn không còn nhận được phần URL của trình giới thiệu cần thiết trong yêu cầu trên nhiều nguồn gốc. Điều này xảy ra khi trình phát hành yêu cầu thay đổi chính sách hoặc khi họ không đặt chính sách và chính sách mặc định của trình duyệt đã thay đổi (như trong Chrome 85).
Để xác định các phương án thay thế, trước tiên, hãy phân tích phần nào của liên kết giới thiệu mà bạn đang sử dụng.
Nếu bạn chỉ cần nguồn gốc
- Nếu bạn đang sử dụng referrer trong một tập lệnh có quyền truy cập cấp cao nhất vào trang, thì
window.location.origin
là một lựa chọn thay thế. - Nếu có, các tiêu đề như
Origin
vàSec-Fetch-Site
sẽ cung cấp cho bạnOrigin
hoặc mô tả liệu yêu cầu có là yêu cầu nhiều nguồn gốc hay không. Đây có thể chính là những gì bạn cần.
Nếu bạn cần các phần tử khác của URL (đường dẫn, tham số truy vấn, v.v.)
- Các tham số yêu cầu có thể giải quyết trường hợp sử dụng của bạn, giúp bạn tiết kiệm công sức phân tích cú pháp liên kết giới thiệu.
- Nếu bạn đang sử dụng referrer trong một tập lệnh có quyền truy cập cấp cao nhất vào trang, thì
window.location.pathname
có thể là một giải pháp thay thế. Chỉ trích xuất phần đường dẫn của URL và truyền phần đó dưới dạng đối số, vì vậy, mọi thông tin có thể nhạy cảm trong tham số URL sẽ không được truyền.
Nếu bạn không thể sử dụng các phương án thay thế này:
- Kiểm tra xem bạn có thể thay đổi hệ thống để yêu cầu trình phát hành yêu cầu (ví dụ:
site-one.example
) đặt rõ ràng thông tin bạn cần trong một số loại cấu hình hay không.- Ưu điểm: rõ ràng hơn, bảo vệ quyền riêng tư hơn cho người dùng
site-one.example
, phù hợp hơn với tương lai. - Nhược điểm: có thể bạn hoặc người dùng hệ thống của bạn sẽ phải làm nhiều việc hơn.
- Ưu điểm: rõ ràng hơn, bảo vệ quyền riêng tư hơn cho người dùng
- Kiểm tra xem trang web phát ra các yêu cầu có đồng ý đặt Referrer-Policy là
no-referrer-when-downgrade
cho mỗi phần tử hoặc mỗi yêu cầu hay không.- Nhược điểm: có thể ít bảo vệ quyền riêng tư hơn cho người dùng
site-one.example
, có thể không được hỗ trợ trong một số trình duyệt.
- Nhược điểm: có thể ít bảo vệ quyền riêng tư hơn cho người dùng
Bảo vệ chống giả mạo yêu cầu trên nhiều trang web (CSRF)
Trình phát hành yêu cầu luôn có thể quyết định không gửi liên kết giới thiệu bằng cách đặt chính sách no-referrer
và thậm chí một tác nhân độc hại có thể giả mạo liên kết giới thiệu.
Sử dụng mã thông báo CSRF làm biện pháp bảo vệ chính. Để tăng cường bảo vệ, hãy sử dụng SameSite và thay vì Referer
, hãy sử dụng các tiêu đề như Origin
(có trên các yêu cầu POST và CORS) và Sec-Fetch-Site
(nếu có).
Ghi nhật ký và gỡ lỗi
Hãy nhớ bảo vệ dữ liệu cá nhân hoặc dữ liệu nhạy cảm của người dùng có thể có trong Referer
.
Nếu bạn chỉ sử dụng nguồn gốc, hãy kiểm tra xem bạn có thể sử dụng tiêu đề Origin
làm phương án thay thế hay không. Điều này có thể cung cấp cho bạn thông tin cần thiết cho mục đích gỡ lỗi theo cách đơn giản hơn và không cần phân tích cú pháp liên kết giới thiệu.
Thanh toán
Nhà cung cấp dịch vụ thanh toán có thể dựa vào tiêu đề Referer
của các yêu cầu đến để kiểm tra bảo mật.
Ví dụ:
- Người dùng nhấp vào nút Mua trên
online-shop.example/cart/checkout
. online-shop.example
chuyển hướng đếnpayment-provider.example
để quản lý giao dịch.payment-provider.example
kiểm traReferer
của yêu cầu này dựa trên danh sách giá trịReferer
được phép do người bán thiết lập. Nếu không khớp với mục nhập nào trong danh sách,payment-provider.example
sẽ từ chối yêu cầu. Nếu khớp, người dùng có thể tiếp tục giao dịch.
Các phương pháp hay nhất để kiểm tra bảo mật quy trình thanh toán
Là nhà cung cấp dịch vụ thanh toán, bạn có thể sử dụng Referer
làm bước kiểm tra cơ bản để chống lại một số cuộc tấn công. Tuy nhiên, tiêu đề Referer
không phải là cơ sở đáng tin cậy để kiểm tra. Trang web yêu cầu, cho dù có phải là người bán hợp pháp hay không, đều có thể đặt chính sách no-referrer
để nhà cung cấp thanh toán không có thông tin Referer
.
Việc xem Referer
có thể giúp các nhà cung cấp dịch vụ thanh toán phát hiện những kẻ tấn công ngây thơ chưa đặt chính sách no-referrer
. Nếu bạn sử dụng Referer
làm bước kiểm tra đầu tiên:
- Đừng mong đợi
Referer
luôn xuất hiện. Nếu có, hãy chỉ so sánh với dữ liệu tối thiểu mà nguồn gốc có thể bao gồm.- Khi đặt danh sách các giá trị
Referer
được phép, hãy đảm bảo chỉ bao gồm nguồn gốc và không có đường dẫn. - Ví dụ: giá trị
Referer
được phép choonline-shop.example
phải làonline-shop.example
, chứ không phảionline-shop.example/cart/checkout
. Bằng cách dự kiến rằng không cóReferer
nào hoặc giá trịReferer
chỉ là nguồn gốc của trang web yêu cầu, bạn sẽ ngăn chặn các lỗi có thể xảy ra do đưa ra giả định vềReferrer-Policy
của người bán.
- Khi đặt danh sách các giá trị
- Nếu không có
Referer
hoặc nếu có và bạn đã kiểm tra thành công nguồn gốcReferer
cơ bản, thì bạn có thể chuyển sang một phương thức xác minh đáng tin cậy hơn.
Để xác minh các khoản thanh toán một cách đáng tin cậy hơn, hãy cho phép bên yêu cầu hàm băm các tham số yêu cầu cùng với một khoá duy nhất. Sau đó, nhà cung cấp dịch vụ thanh toán có thể tính toán cùng một hàm băm ở phía bạn và chỉ chấp nhận yêu cầu nếu hàm băm đó khớp với kết quả tính toán của bạn.
Điều gì sẽ xảy ra với Referer
khi một trang web người bán HTTP không có chính sách liên kết chuyển hướng đến một nhà cung cấp dịch vụ thanh toán HTTPS?
Không có Referer
nào xuất hiện trong yêu cầu gửi đến nhà cung cấp dịch vụ thanh toán HTTPS, vì hầu hết trình duyệt sử dụng strict-origin-when-cross-origin
hoặc no-referrer-when-downgrade
theo mặc định khi trang web không đặt chính sách.
Việc Chrome thay đổi sang chính sách mặc định mới sẽ không làm thay đổi hành vi này.
Kết luận
Chính sách bảo vệ liên kết giới thiệu là một cách hiệu quả để mang lại cho người dùng nhiều quyền riêng tư hơn.
Để tìm hiểu thêm về các kỹ thuật bảo vệ người dùng, hãy xem tuyển tập An toàn và bảo mật của chúng tôi
Tài nguyên
- Tìm hiểu về "cùng trang web" và "cùng nguồn gốc"
- Tiêu đề bảo mật mới: Chính sách liên kết (2017)
- Referrer-Policy trên MDN
- Tiêu đề liên kết giới thiệu: các vấn đề về quyền riêng tư và bảo mật trên MDN
- Thay đổi đối với Chrome: ý định Blink để triển khai
- Thay đổi đối với Chrome: ý định Blink sẽ được phân phối
- Thay đổi đối với Chrome: mục nhập trạng thái
- Thay đổi đối với Chrome: Bài đăng trên blog về bản thử nghiệm 85
- Luồng GitHub về việc cắt bớt tệp giới thiệu: những gì các trình duyệt khác nhau làm
- Thông số kỹ thuật về chính sách giới thiệu
Xin cảm ơn tất cả những người đã đóng góp và phản hồi, đặc biệt là Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck và Kayce Basques.