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
Maud Nalpas
X GitHub

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 đườ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 không mong muốn trên nhiều nguồn gốc gây tổn hại đến quyền riêng tư của người dùng web. Chính sách liên kết giới thiệu bảo vệ có thể giúp ích cho bạn.
  • Hãy cân nhắc việc đặt một chính sách liên kết giới thiệu là strict-origin-when-cross-origin. API này duy trì hầu hết tính hữu ích của đường liên kết giới thiệu, đồng thời giảm thiểu nguy cơ 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). Thay vào đó, hãy 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.

Chính sách giới thiệu và 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. Tiêu đề này cho biết nguồn gốc hoặc URL của trang web đã thực hiện yêu cầu. 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à từ đó yêu cầu được thực hiện.

Yêu cầu HTTP bao gồm tiêu đề Giới thiệ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 chỉ đườ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 một 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 các thao tác điều hướng và iframe, bạn cũng có thể truy cập dữ liệu này bằng JavaScript bằng document.referrer.

Bạn có thể học hỏi được rất nhiều từ các giá trị của Referer. Ví dụ: một dịch vụ phân tích có thể sử dụng những dữ liệu này để xác định rằng 50% 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ì URL 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:

Các URL có đường dẫn, được ánh xạ đến nhiều mức độ 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ư và tính bảo mật của người dùng.

Các 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 tiết lộ những nguồn này một cách ngầm ẩn có thể xâm phạm quyền riêng tư của người dùng web.

URL số 6 là một URL chức năng. Nếu có bất kỳ ai không phải người dùng mong muốn nhận được lệnh này, thì kẻ xấu có thể giành quyền 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 giới thiệu nào đượ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 đối với đường liên kết giới thiệu.

Hiện 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 trong 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
Dữ liệu có thể nằm trong tiêu đề Người giới thiệu và document.referrer.
Ví dụ về dữ liệu tham chiế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 ngữ cảnh: yêu cầu trên nhiều nguồn gốc hoặc cùng nguồn gốc, cho dù đích đến của yêu cầu có bảo mật như nguồn gốc hay không, hay 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 tới các nguồn gốc kém an toàn hơn, trong khi vẫn duy trì sự phong phú của đường liên kết giới thiệu trong chính trang web của bạn.

Bảng sau đây cho biết cách các chính sách liên kết giới thiệu hạn chế dữ liệu URL có trong tiêu đề Tham chiế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 Phương thức tham chiếu: Chỉ nguồn gốc Tham chiếu: URL đầy đủ
Không xem xét ngữ 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 đến HTTP
no-referrer-when-downgrade Yêu cầu từ HTTPS sang HTTP Yêu cầu từ HTTPS sang HTTPS
hoặc từ HTTP đến HTTP
Tập trung vào quyền riêng tư origin-when-cross-origin Yêu cầu nhiều nguồn gốc Yêu cầu cùng nguồn gốc
same-origin Yêu cầu 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 từ 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 thiết lập chính sách liên kết giới thiệu:

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

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

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.
Kể từ phiên bản 93, đối với người dùng tính năng Chống theo dõi nghiêm ngặt và Duyệt web riêng tư, các chính sách liên kết giới thiệu ít hạn chế hơn 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à đường 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ể trang web có chính sách nào.
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ố điểm khác biệt cụ thể. Hãy xem bài viết Ngăn chặn việc theo dõi tính năng 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 để thiết lập chính sách liên kết giới thiệu cho trang web của bạn:

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. Sau đây là thứ tự ưu tiên để xác định chính sách có hiệu lực của một phần tử:

  1. Chính sách ở cấp phần tử
  2. Chính sách cấp trang
  3. 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 đều tuân theo chính sách strict-origin-when-cross-origin.

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

securityheaders.com rất hữu ích trong việc 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ô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 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 sẽ hiển thị Referer đã được 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, cho thấy Trình giới thiệu và Chính sách giới thiệu (Referrer-Policy).
Bảng điều khiển Mạng của Công cụ của Chrome cho nhà phát triển 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 một chính sách tăng cường bảo vệ quyền riêng tư, chẳng hạn như strict-origin-when-cross-origin (hoặc nghiêm ngặt hơn).

Tại sao nên "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 tuân theo chế độ mặc định của trình duyệt. Nhưng điều này không lý tưởng vì:

  • Các trình duyệt khác nhau có chính sách mặc định khác nhau, vì vậy nếu bạn dựa vào chế độ mặc định của 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 sử 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 liên kết giới thiệu cho các yêu cầu trên nhiều nguồn gốc. Việc chọn áp dụng chính sách tăng cường quyền riêng tư một cách rõ ràng trước khi các chế độ mặc định của trình duyệt thay đổi sẽ giúp bạn có quyền kiểm soát và chạy các chương trình kiểm thử khi 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, nâng cao quyền riêng tư và hữu ích. "Hữu ích" có nghĩa là gì phụ thuộc vào điều bạn muốn từ liên kết 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 giao thức này), thì bạn sẽ không muốn URL của trang web bị rò rỉ trong các yêu cầu không phải loại HTTPS. Vì bất kỳ ai trên mạng đều có thể thấy các dữ liệu này, nên việc rò rỉ dữ liệu sẽ khiến người dùng của bạn bị tấn công xen giữa. Các chính sách no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer và strict-origin giải quyết vấn đề này.
  • Tăng cường quyền riêng tư: đối với một yêu cầu nhiều nguồn gốc, no-referrer-when-downgrade sẽ 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ỉ chia sẻ nguồn gốc, còn no-referrer không chia sẻ gì cả. Khi đó, bạn sẽ thấy strict-origin-when-cross-origin, strict-origin và no-referrer dưới dạng các tuỳ chọn 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 đủ, thì 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ụ: Đặ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ụ trong Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Nếu strict-origin-when-cross-origin (hoặc nghiêm ngặt hơn) không phù hợp với tất cả các trường hợp sử dụng của bạn thì sao?

Trong trường hợp này, hãy thực hiện phương pháp tăng dần: đặ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, hãy đặt một chính sách cho phép nhiều hơn đố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 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'});

Còn điều gì khác bạn nên cân nhắc?

Chính sách nên phụ thuộc vào trang web và trường hợp sử dụng, do bạn, nhóm và công ty của bạn quyết định. Nếu một số URL chứa dữ liệu nhận dạng hoặc nhạy cảm, hãy đặt 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

Dưới đâ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 được gửi đế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 nhận dạng, vì vậy, hãy đảm bảo bạn xử lý dữ liệu đó theo cách đó.

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 gửi đến nhiều nguồn gốc 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, thì bạn không thể giả định về tiêu đề Referer (và document.referrer) mà bạn nhận được. 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 thường là chuyển sang một chính sách nghiêm ngặt hơn so với chính sách đã sử dụng trước đây. Đ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.
  • 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à hiện tại, bạn có thể chỉ nhận được URL gốc, thay vì URL liên kết giới thiệu đầy đủ, trong các yêu cầu gửi đến nhiều nguồn gốc, nếu trang web của người gửi chưa thiết lập 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 đường 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ụ: có thể có URL đầy đủ khi bạn chỉ muốn biết yêu cầu có phải trên nhiều nguồn gốc hay không.

Lựa chọn thay thế cho Referer

Bạn có thể cần phải xem xét 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 liên kết giới thiệu của các yêu cầu gửi đến nhiều nguồn gốc.
  • Trang web của bạn không còn nhận được 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 chính sách hoặc khi trình phát chưa đặt chính sách đồng thời chính sách của trình duyệt mặc định thay đổi (chẳng hạn 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 phần nào của đường 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 đườ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, thì window.location.origin là giải pháp thay thế.
  • Nếu có, các tiêu đề như Origin và Sec-Fetch-Site sẽ cung cấp cho bạn Origin hoặc mô tả liệu yêu cầu có phải trên nhiều nguồn gốc hay không, đây có thể chính xác 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 việc phân tích cú pháp đường liên kết giới thiệu.
  • Nếu bạn đang sử dụng đườ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, thì window.location.pathname có thể hoạt động thay thế. Chỉ trích xuất phần đường dẫn của URL và chuyển phần này làm đối số, để không chuyển mọi thông tin có thể có tính chất nhạy cảm trong tham số URL.

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

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

Biện pháp bảo vệ trước Hành vi 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 đường liên kết giới thiệu bằng cách đặt chính sách no-referrer, và một tác nhân ác ý thậm chí còn có thể giả mạo đường liên kết giới thiệu.

Hãy dùng mã thông báo CSRF làm biện pháp bảo vệ chính. Để tăng cường mức độ 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ó sẵn trong 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 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 liệu bạn có thể dùng tiêu đề Origin làm tiêu đề thay thế hay không. Thao tác này có thể cung cấp 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 đườ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 gửi đế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 với danh sách các giá trị Referer được phép do người bán thiết lập. Nếu yêu cầu này không khớp với bất kỳ 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 phương thứ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ể thiết lập chính sách no-referrer để không cung cấp thông tin Referer cho nhà cung cấp dịch vụ thanh toán.

Việc xem xét Referer có thể giúp 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:

  • Không phải lúc nào Referer cũng xuất hiện. Nếu có, hãy kiểm tra chỉ số này 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 đảm bảo chỉ bao gồm gốc 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. Khi dự kiến 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ác lỗi có thể xảy ra do giả định về Referrer-Policy của người bán.
  • Nếu không có Referer hoặc nếu phương thức này có mặt và quá trình kiểm tra nguồn gốc Referer cơ bản đã thành công, thì 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 để người yêu cầu 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 yêu cầu khớp với cách 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ó chính sách liên kết giới thiệu 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 tới nhà cung cấp dịch vụ thanh toán HTTPS, vì hầu hết các trình duyệt đều 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. Việc Chrome thay đổi thành một 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 giới thiệu bảo vệ là một cách hay để 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 giúp bảo vệ người dùng, hãy xem quy trình thu thập An toàn và bảo mật của chúng tôi

Tài nguyên

Chúng tôi chân thành cảm ơn những đóng góp và ý kiến phản hồi của tất cả người đánh giá, đặc biệt là Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck và Kayce Basques.