Trang này được dịch bởi Cloud Translation API.

Các phương pháp hay nhất về Giới thiệu và Chính sách giới thiệu

Maud Nalpas

Trang này trình bày một số phương pháp hay nhất để đặt Chính sách liên kết giới thiệu và bằng cách sử dụng liên kết giới thiệu trong các yêu cầu được gửi đến.

Tóm tắt

Sự cố rò rỉ thông tin trên nhiều nguồn gốc gây thiệt hại không mong muốn cho người dùng web quyền riêng tư. Đáp chính sách người giới thiệu bảo vệ có thể giúp bạn khắc phục vấn đề này.
Hãy cân nhắc đặt chính sách đường liên kết giới thiệu là strict-origin-when-cross-origin. Nó bảo toàn tính hữu ích của đường liên kết giới thiệu, đồng thời giảm thiểu rủi ro làm rò rỉ dữ liệu trên nhiều nguồn gốc.
Đừng sử dụng đường liên kết giới thiệu cho biện pháp bảo vệ Giả mạo yêu cầu trên nhiều trang web (CSRF). Sử dụng Mã thông báo CSRF và các tiêu đề khác làm lớp bảo mật bổ sung.

Giới thiệu và chính sách giới thiệu 101

Các yêu cầu HTTP có thể bao gồm một tiêu đề Referer (không bắt buộc), cho biết nguồn gốc hoặc URL trang web nơi thực hiện yêu cầu. Chiến lược phát hành đĩa đơ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 hoàn chỉnh của trên site-one nơi gửi yêu cầu.

Yêu cầu HTTP bao gồm tiêu đề Tham chiếu. — Yêu cầu HTTP có tiêu đề Tham chiếu.

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 về 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à một trang cần.

Đối với điều hướng và iframe, bạn cũng có thể truy cập dữ liệu này bằng JavaScript sử dụng document.referrer.

Bạn có thể học hỏi được nhiều điều từ các giá trị của Referer. Ví dụ: dịch vụ phân tích có thể sử dụng chúng để xác định rằng 50% khách truy cập vào site-two.example đến từ social-network.example. Nhưng khi URL đầy đủ, bao gồm cả đường dẫn và chuỗi truy vấn, được gửi trong Referer trên các nguồn gốc, nên có thể gây nguy hiểm cho người dùng quyền riêng tư và tiềm ẩn rủi ro về bảo mật:

URL có đường dẫn, được liên kết với nhiều rủi ro về quyền riêng tư và bảo mật. — Việc sử dụng URL đầy đủ có thể ảnh hưởng đến quyền riêng tư của người dùng và 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 cá nhân. Việc ngầm ẩn những dữ liệu này trên các nguồn gốc có thể gây hại của người dùng web quyền riêng tư.

URL số 6 là một URL chức năng. Nếu có Nếu người dùng mong muốn nhận được email này, thì kẻ xấu có thể kiểm soát của tài khoản người dùng này.

Để hạn chế việc cung cấp dữ liệu về đường liên kết giới thiệu cho các yêu cầu từ trang web của bạn, bạn có thể thiết lập chính sách đường liên kết giới thiệu.

Những chính sách nào được cung cấp 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 trong tiêu đề Referer (và document.referrer) có thể là:

Không có dữ liệu (không có tiêu đề Referer)
Chỉ origin
URL đầy đủ: nguồn gốc, đường dẫn và chuỗi truy vấn

Dữ liệu có thể
có trong tiêu đề Tham chiếu và document.referrer. — Ví dụ về dữ liệu Giới thiệu.

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 bối cảnh: của yêu cầu trên nhiều nguồn gốc hay cùng nguồn gốc, cho dù đích đến của yêu cầu là bảo mật làm nguồn gốc hoặc cả hai. Điều này giúp 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 ít an toàn hơn, trong khi vẫn duy trì được tính 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 trình bày cách chính sách về đường liên kết giới thiệu hạn chế dữ liệu về URL từ tiêu đề Giới thiệu và document.referrer:

Phạm vi áp dụng chính sách	Tên chính sách	Tham chiếu: Không có dữ liệu	Tham chiếu: Chỉ nguồn gốc	Giới thiệu: URL đầy đủ
Không xem xét bối cảnh của yêu cầu	`no-referrer`	dấu kiểm
	`origin`		dấu kiểm
	`unsafe-url`			dấu kiểm
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 từ HTTP sang HTTP
Tập trung vào bảo mật	`no-referrer-when-downgrade`	Yêu cầu từ HTTPS sang HTTP		Yêu cầu từ HTTPS sang HTTPS hoặc từ 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
Tập trung vào quyền riêng tư	`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à tính 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 từ HTTP đến 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à hành vi ví dụ.

Sau đây là một số điều cần lưu ý khi đặt chính sách về đường liên kết giới thiệu:

Tất cả các chính sách xem xét lược đồ (HTTPS so với HTTP) (strict-origin, no-referrer-when-downgrade và strict-origin-when-cross-origin) xử lý các yêu cầu từ một nguồn gốc HTTP tới 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 khác Nguồn gốc HTTPS, mặc dù HTTP kém an toàn hơn. Đó là vì đối với chính sách của Google, điều quan trọng là liệu hạ cấp bảo mật có diễn ra hay không; để là, nếu yêu cầu có thể tiết lộ dữ liệu từ một nguồn gốc đã mã hoá tới một một, như trong HTTPS → yêu cầu HTTP. Yêu cầu HTTP → HTTP hoàn toàn chưa mã hoá, nên không thể hạ cấp.
Nếu một yêu cầu có cùng nguồn gốc, thì giao thức đó (HTTPS hoặc HTTP) đang như nhau, do đó không hạ cấp bảo mật.

Chính sách đường 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 đường liên kết giới thiệu nào, trình duyệt sẽ sử dụng chính sách mặc định của trình duyệt đó.

Trình duyệt	`Referrer-Policy` / Hành vi mặc định
Chrome	Mặc định là `strict-origin-when-cross-origin`.
Firefox	Mặc định là `strict-origin-when-cross-origin`. Bắt đầu từ phiên bản 93, dành cho người dùng tính năng Chống theo dõi nghiêm ngặt và Duyệt web ở chế độ riêng tư, chính sách liên kết giới hạn hạn chế `no-referrer-when-downgrade`, `origin-when-cross-origin` và `unsafe-url` là bị bỏ qua đối với các yêu cầu trên nhiều trang web, nghĩa là đường liên kết giới thiệu luôn bị cắt bớt cho 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	Chế độ mặc định tương tự như `strict-origin-when-cross-origin`, với một số khác biệt cụ thể. Xem Ngăn việc theo dõi tính năng chống 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 về đường liên kết giới thiệu

Mục tiêu: Đặt rõ ràng một chính sách tăng cường quyền riêng tư, chẳng hạn như strict-origin-when-cross-origin(hoặc nghiêm ngặt hơn).

Có nhiều cách để đặt chính sách đường 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 theo cơ sở theo từng 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 cho cách xác định chính sách có hiệu lực của một yếu 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 theo chính sách no-referrer-when-downgrade và tất cả các chính sách khác các yêu cầu về tài nguyên phụ từ trang này tuân theo 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ụ cho nhà phát triển trong Chrome, Edge hoặc Firefox để xem chính sách đường liên kết giới thiệu được 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 tiêu đề Referrer-Policy nhưng cho thấy Referer đã gửi.

Ảnh chụp màn hình bảng điều khiển Mạng của Công cụ của Chrome cho nhà phát triển, trong đó cho thấy chính sách về tham chiếu và liên kết giới thiệu. — Công cụ của Chrome cho nhà phát triển Bảng điều khiển **Mạng** với một yêu cầu được chọn.

Bạn nên đặt chính sách nào cho trang web của mình?

Bạn nên thiết lập rõ ràng chính sách tăng cường bảo mật, chẳng hạn như strict-origin-when-cross-origin (hoặc nghiêm ngặt hơn).

Tại sao nên chọn "một cách rõ ràng"?

Nếu bạn không đặt chính sách liên kết giới thiệu, 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 làm theo 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 trình duyệt trang web của bạn sẽ không hoạt động như dự đoán trên các trình duyệt.
Các trình duyệt đang áp dụng các chế độ mặc định nghiêm ngặt hơn như strict-origin-when-cross-origin và các cơ chế như cắt bỏ đường liên kết giới thiệu cho các yêu cầu trên nhiều nguồn gốc. Chọn tham gia một cách rõ ràng một chính sách nâng cao quyền riêng tư trước khi thay đổi về giá trị mặc định của trình duyệt cho phép bạn kiểm soát và giúp bạn chạy các thử nghiệm mà bạn thấy phù hợp.

Tại sao nên chọn `strict-origin-when-cross-origin` (hoặc nghiêm ngặt hơn)?

Bạn cần một chính sách bảo mật, tăng cường quyền riêng tư và hữu ích. Giá trị "hữu ích" có nghĩa là tuỳ thuộc vào những gì bạn muốn từ liên kết giới thiệu:

An toàn: nếu trang web của bạn sử dụng HTTPS (nếu không, hãy đặt trang web thành một ưu tiên), bạn sẽ không muốn URL của trang web bị rò rỉ các yêu cầu không phải HTTPS. Vì bất kỳ ai trên mạng cũng có thể thấy những thông tin này nên rò rỉ thông tin khiến người dùng bị tấn công xen giữa. Chính sách no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer và strict-origin sẽ giải bài toán này.
Tăng cường quyền riêng tư: đối với yêu cầu nhiều nguồn gốc, no-referrer-when-downgrade chia sẻ URL đầy đủ, điều này có thể gây ra các vấn đề về quyền riêng tư. strict-origin-when-cross-origin và strict-origin chỉ có chung nguồn gốc, và no-referrer không chia sẻ gì. Điều này sẽ mang lại cho bạn strict-origin-when-cross-origin, strict-origin và no-referrer dưới dạng các tuỳ chọn tăng cường bảo vệ quyền riêng tư.
Hữu ích: no-referrer và strict-origin không bao giờ chia sẻ URL đầy đủ, ngay cả khi cho 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 trên có nghĩa là strict-origin-when-cross-origin thường là một lựa chọn hợp lý.

Ví dụ: Đặt 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 phù hợp với mọi trường hợp sử dụng của bạn?

Trong trường hợp này, hãy sử dụng phương pháp tiếp cận tiến bộ: đặt mộ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, chính sách thoải mái đối với 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 đối với yêu cầu trên nhiều trang web. Xem 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 yếu tố nào khác?

Chính sách phải phụ thuộc vào trang web và các trường hợp sử dụng của bạn (do bạn xác định), đội nhóm và công ty của bạn. Nếu một số URL chứa dữ liệu nhận dạng hoặc dữ liệu nhạy cảm, thiết lập một chính sách bảo vệ.

Các phương pháp hay nhất cho yêu cầu được gửi đến

Sau đây là một số nguyên tắc về những việc cần làm nếu trang web của bạn sử dụng URL liên kết giới thiệu của các yêu cầu đến.

Bảo vệ người dùng dữ liệu

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 đối xử với nó như vậy.

Các liên kết giới thiệu đến có thể thay đổi {referer-can-change}

Việc sử dụng đường liên kết giới thiệu từ các yêu cầu đến từ nhiều nguồn có một số hạn chế như sau:

Nếu không có quyền kiểm soát việc triển khai trình phát 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. Trình phát yêu cầu có thể quyết định chuyển sang chính sách no-referrer bất cứ lúc nào hoặc nói chung là áp dụng một chính sách nghiêm ngặt hơn chính sách từng sử dụng. Điều này có nghĩa là bạn sẽ nhận được ít dữ liệu hơn từ Referer so với trước đây.
Các trình duyệt ngày càng sử dụng Referrer-Policy strict-origin-when-cross-origin theo mặc định. Điều này có nghĩa là giờ đây, bạn có thể chỉ nhận được dữ liệu gốc, thay vì một URL liên kết giới thiệu đầy đủ trong các yêu cầu đến từ nhiều nguồn gốc, nếu trang web của người gửi chưa đặt chính sách nào.
Các trình duyệt có thể thay đổi cách quản lý Referer. Ví dụ: một số trình duyệt nhà phát triển có thể quyết định luôn cắt bớt đường liên kết giới thiệu đến các nguồn gốc trên nhiều nguồn gốc yêu cầu về tài nguyên phụ để 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 bạn cần. Ví dụ: trang đó có thể có URL đầy đủ khi bạn chỉ muốn biết liệu yêu cầu có nhiều nguồn gốc.

Lựa chọn thay thế cho `Referer`

Bạn có thể cần cân nhắc các phương án thay thế nếu:

Một tính năng thiết yếu của trang web của bạn sử dụng URL liên kết giới thiệu của yêu cầu trên nhiều nguồn gốc.
Trang web của bạn không còn nhận được một phần của URL liên kết giới thiệu mà trang web cần 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 yêu cầu thay đổi 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 lựa chọn thay thế, trước tiên, hãy phân tích xem bạn đang sử dụng phần nào của đường liên kết giới thiệu.

Nếu bạn chỉ cần nguồn gốc

Nếu bạn đang sử dụng liên kết giới thiệu trong một tập lệnh có quyền truy cập cấp cao nhất vào trang, window.location.origin là một giải pháp thay thế.
Nếu có, các tiêu đề như Origin và Sec-Fetch-Site cung cấp cho bạn Origin hoặc mô tả xem yêu cầu có phải là trên nhiều nguồn gốc hay không. Điều này có thể chính xác là những gì bạn cần.

Nếu bạn cần các thành phần khác của URL (đường dẫn, tham số truy vấn, v.v.)

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 việc phân tích cú pháp liên kết giới thiệu.
Nếu bạn đang sử dụng liên kết giới thiệu trong một tập lệnh có quyền truy cập cấp cao nhất vào trang, window.location.pathname có thể là giải pháp thay thế. Chỉ trích xuất đường dẫn của URL và chuyển nó vào dưới dạng đối số, để bất kỳ trong các tham số URL không được chuyển tiếp.

Nếu bạn không thể sử dụng các lựa chọn thay thế này:

Kiểm tra xem bạn có thể thay đổi hệ thống để mong đợi trình phát yêu cầu hay không (ví dụ: site-one.example) để nêu rõ thông tin bạn cần trong một số loại cấu hình.
- Ưu điểm: rõ ràng hơn và bảo đảm 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ể nhiều công việc ở phía bạn hoặc cho người dùng hệ thống của bạn.
Kiểm tra xem trang web đưa ra yêu cầu có đồng ý đặt cho mỗi phần tử hoặc Chính sách liên kết giới thiệu theo mỗi yêu cầu của no-referrer-when-downgrade.
- Nhược điểm: site-one.example người dùng có thể ít bảo đảm quyền riêng tư hơn, có thể không được hỗ trợ trong tất cả các trình duyệt.

Biện pháp bảo vệ Giả mạo yêu cầu trên nhiều trang web (CSRF)

Trình phát 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 cài đặt no-referrer và đối tượng xấu thậm chí có thể giả mạo đường 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 khả năng bảo vệ, hãy sử dụng SameSite và thay vì Referer, hãy sử dụng tiêu đề như Origin (có sẵn cho 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 đảm bảo rằng bạn bảo vệ dữ liệu cá nhân hoặc dữ liệu nhạy cảm có thể nằm trong Referer.

Nếu bạn chỉ đang sử dụng nguồn gốc, hãy kiểm tra xem bạn có thể sử dụng Origin tiêu đề dưới dạng một giải pháp thay thế. Thao tác này có thể cung cấp cho bạn thông tin bạn cần để gỡ lỗi một cách đơn giản hơn mà không cần phải phân tích cú pháp của đường 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 đến payment-provider.example để quản lý giao dịch.
payment-provider.example kiểm tra Referer của yêu cầu này so với một danh sách trong số giá trị Referer được phép do người bán thiết lập. Nếu mã này không khớp với bất kỳ trong danh sách, payment-provider.example sẽ từ chối yêu cầu. Nếu có , 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 séc cơ bản đối với một số cuộc tấn công. Tuy nhiên, bản thân tiêu đề Referer không phải là cơ sở đáng tin cậy để một tấm séc. Trang web yêu cầu, cho dù họ có phải là người bán hợp pháp hay không, có thể đặt Chính sách no-referrer khiến thông tin về Referer không hiển thị nhà cung cấp dịch vụ thanh toán khác.

Việc xem xét Referer có thể giúp các nhà cung cấp dịch vụ thanh toán phát hiện được 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 kiểm tra chỉ dựa trên dữ liệu tối thiểu mà nó có thể bao gồm, đó là nguồn gốc.
- Khi đặt danh sách các giá trị Referer được phép, hãy nhớ chỉ cung cấp và không có đường dẫn.
- Ví dụ: các giá trị Referer được phép cho online-shop.example phải là online-shop.example, chứ không phải online-shop.example/cart/checkout. Dự kiến hoàn toàn không có Referer hoặc giá trị Referer chỉ là yêu cầu nguồn gốc của trang web, giúp ngăn chặn các lỗi có thể xuất phát từ việc đưa ra giả định về Referrer-Policy của người bán.
Nếu không có Referer, hoặc nếu có và nguồn gốc Referer cơ bản của bạn bước kiểm tra đã thành công, bạn có thể chuyển sang một phương thức xác minh khác đá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 người yêu cầu xác minh băm các thông 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 nó phù hợp với tính toán của bạn.

Điều gì sẽ xảy ra với Referer khi trang web của người bán sử dụng giao thức HTTP không có đường liên kết giới thiệu chính sách này chuyển hướng đến một nhà cung cấp dịch vụ thanh toán HTTPS?

Không có Referer nào hiển thị trong yêu cầu gửi đến nhà cung cấp dịch vụ thanh toán HTTPS, vì hầu hết các 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 nào. Thay đổi của Chrome sang chính sách mặc định mới sẽ không thay đổi hành vi này.

Kết luận

Chính sách về người giới thiệu bảo vệ là một cách hiệu quả để tăng cường quyền riêng tư cho người dùng.

Để tìm hiểu thêm về các kỹ thuật khác nhau nhằm bảo vệ người dùng của bạn, hãy xem Bộ sưu tập an toàn và bảo mật

Tài nguyên

Cảm ơn bạn đã đóng góp và gửi ý kiến phản hồi cho tất cả những người đánh giá, đặc biệt là Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck và Kayce Basques.

Các phương pháp hay nhất về Giới thiệu và Chính sách giới thiệu

Tóm tắt

Giới thiệu và chính sách giới thiệu 101

Những chính sách nào được cung cấp và chúng khác nhau như thế nào?

Chính sách đường liên kết giới thiệu mặc định trong trình duyệt

Các phương pháp hay nhất để thiết lập chính sách về đường liên kết giới thiệu

Làm cách nào để xem chính sách về đường liên kết giới thiệu?

Bạn nên đặt chính sách nào cho trang web của mình?

Tại sao nên chọn "một cách rõ ràng"?

Tại sao nên chọn strict-origin-when-cross-origin (hoặc nghiêm ngặt hơn)?

Điều gì sẽ xảy ra nếu strict-origin-when-cross-origin (hoặc nghiêm ngặt hơn) không phù hợp với mọi trường hợp sử dụng của bạn?

Ví dụ: chính sách ở cấp phần tử

Ví dụ: chính sách ở cấp yêu cầu

Bạn nên cân nhắc những yếu tố nào khác?

Các phương pháp hay nhất cho yêu cầu được gửi đến

Bảo vệ người dùng dữ liệu

Các liên kết giới thiệu đến có thể thay đổi {referer-can-change}

Lựa chọn thay thế cho Referer

Nếu bạn chỉ cần nguồn gốc

Nếu bạn cần các thành phần khác của URL (đường dẫn, tham số truy vấn, v.v.)

Nếu bạn không thể sử dụng các lựa chọn thay thế này:

Biện pháp bảo vệ Giả mạo yêu cầu trên nhiều trang web (CSRF)

Ghi nhật ký và gỡ lỗi

Thanh toán

Các phương pháp hay nhất để kiểm tra bảo mật quy trình thanh toán

Kết luận

Tài nguyên

Tại sao nên chọn `strict-origin-when-cross-origin` (hoặc nghiêm ngặt hơn)?

Điều gì sẽ xảy ra nếu `strict-origin-when-cross-origin` (hoặc nghiêm ngặt hơn) không phù hợp với mọi trường hợp sử dụng của bạn?

Lựa chọn thay thế cho `Referer`