בדף הזה מפורטות כמה שיטות מומלצות להגדרת מדיניות הגורם המפנה ולשימוש בגורם המפנה בבקשות נכנסות.
סיכום
- דליפה לא צפויה של מידע ממקורות שונים פוגעת בפרטיות של משתמשי האינטרנט. מדיניות מגינה לגורם מפנה יכולה לעזור.
- כדאי להגדיר מדיניות לגורם מפנה של
strict-origin-when-cross-origin
. הוא משמר את רוב השימושיות של הגורם המפנה, ומצמצם את הסיכון להדלפת נתונים ממקורות שונים. - אין להשתמש בגורמים מפנים לצורך הגנה מפני זיוף בקשות באתרים שונים (CSRF). במקום זאת, כדאי להשתמש באסימוני CSRF ובכותרות אחרות כשכבת אבטחה נוספת.
101 מדיניות של גורם מפנה וגורם מפנה
בקשות HTTP יכולות לכלול כותרת Referer
אופציונלית, שמציינת את המקור או את כתובת ה-URL של דף האינטרנט שממנו נשלחה הבקשה. הכותרת Referrer-Policy
מגדירה אילו נתונים זמינים בכותרת Referer
.
בדוגמה הבאה, הכותרת Referer
כוללת את כתובת ה-URL המלאה של הדף ב-site-one
שממנו נשלחה הבקשה.
![בקשת HTTP כולל כותרת של הגורם המפנה.](https://web.dev/static/articles/referrer-best-practices/image/http-request-including-r-9ebf692a22831.jpg?authuser=5&hl=he)
הכותרת Referer
עשויה להופיע בסוגים שונים של בקשות:
- בקשות ניווט, כשמשתמש לוחץ על קישור.
- בקשות למשאבי משנה, כשדפדפן מבקש תמונות, iframes, סקריפטים ומשאבים אחרים שנדרשים לדף.
לניווטים ולמסגרות iframe, אפשר גם לגשת לנתונים האלה באמצעות JavaScript באמצעות document.referrer
.
אפשר ללמוד הרבה מהערכים של Referer
. לדוגמה, שירות ניתוח נתונים עשוי להשתמש בהם כדי לקבוע ש-50% מהמבקרים ב-site-two.example
הגיעו מ-social-network.example
. אבל כתובת ה-URL המלאה, כולל הנתיב ומחרוזת השאילתה, נשלחת ב-Referer
בכל המקורות, עלולה לסכן את פרטיות המשתמשים וליצור סיכוני אבטחה:
![כתובות URL עם נתיבים שממופות לסיכוני פרטיות ואבטחה שונים.](https://web.dev/static/articles/referrer-best-practices/image/urls-paths-mapped-diff-5b35e579c46d7.jpg?authuser=5&hl=he)
כתובות URL מס' 1 עד מס' 5 מכילות מידע פרטי, ולפעמים מידע רגיש או מידע מזהה. הדלפה שקטה של מידע כזה ממקורות שונים עלולה לפגוע בפרטיות של משתמשי האינטרנט.
כתובת URL מס' 6 היא כתובת URL של קיבולת. אם מישהו שהוא לא המשתמש המיועד מקבל את ההודעה הזו, גורם זדוני יכול להשתלט על החשבון של המשתמש הזה.
כדי להגביל את הנתונים של הגורמים המפנים שיהיו זמינים לבקשות מהאתר שלכם, אפשר להגדיר מדיניות לגורם מפנה.
אילו כללי מדיניות זמינים ובמה הם שונים?
אפשר לבחור אחד מתוך שמונה כללי מדיניות. בהתאם למדיניות, הנתונים שזמינים מהכותרת Referer
(וגם document.referrer
) יכולים להיות:
- אין נתונים (אין כותרת
Referer
) - רק הערך origin
- כתובת ה-URL המלאה: מקור, נתיב ומחרוזת שאילתה
![נתונים שיכולים להיכלל בכותרת הגורם המפנה וב-document.referrer.](https://web.dev/static/articles/referrer-best-practices/image/data-can-contained-the-209ad524f7ae8.jpg?authuser=5&hl=he)
כללי מדיניות מסוימים נועדו להתנהג באופן שונה בהתאם להקשר: בקשות ממקורות שונים או בקשות מאותו מקור, אם יעד הבקשה מאובטח כמו המקור או שניהם. האפשרות הזו שימושית כדי להגביל את כמות המידע שמשותף בין מקורות או למקורות פחות מאובטחים, תוך שמירה על העושר של הגורם המפנה באתר שלכם.
הטבלה הבאה מראה איך המדיניות לגורם מפנה מגבילה את הנתונים של כתובות ה-URL הזמינים בכותרת הגורם המפנה וב-document.referrer
:
היקף המדיניות | שם מדיניות | מפנה: אין נתונים | מקור הפניה: מקור בלבד | מפנה: כתובת URL מלאה |
---|---|---|---|---|
לא כולל את ההקשר של הבקשה | no-referrer |
בדיקה | ||
origin |
בדיקה | |||
unsafe-url |
בדיקה | |||
ממוקד באבטחה | strict-origin |
בקשה מ-HTTPS ל-HTTP | בקשה מ-HTTPS ל-HTTPS או מ-HTTP ל-HTTP |
|
no-referrer-when-downgrade |
בקשה מ-HTTPS ל-HTTP | בקשה מ-HTTPS ל-HTTPS או מ-HTTP ל-HTTP |
||
ממוקד בפרטיות | origin-when-cross-origin |
בקשה ממקורות שונים | בקשה מאותו מקור | |
same-origin |
בקשה ממקורות שונים | בקשה מאותו מקור | ||
דגש על פרטיות ואבטחה | strict-origin-when-cross-origin |
בקשה מ-HTTPS ל-HTTP | בקשה ממקורות שונים מ-HTTPS ל-HTTPS או מ-HTTP ל-HTTP |
בקשה מאותו מקור |
MDN מספק רשימה מלאה של כללי מדיניות ודוגמאות להתנהגות.
הנה כמה דברים שכדאי לדעת בעת הגדרת מדיניות לגורם מפנה:
- כל כללי המדיניות שמבוססים על הסכימה (HTTPS לעומת HTTP) בחשבון (
strict-origin
,no-referrer-when-downgrade
ו-strict-origin-when-cross-origin
) מתייחסים לבקשות ממקור HTTP אחד למקור HTTP אחר באותו אופן כמו בקשות ממקור HTTPS למקור HTTPS אחר, למרות ש-HTTP פחות מאובטח. הסיבה לכך היא שבכללי המדיניות האלה, מה שחשוב הוא האם מתבצעת שדרוג לאחור של האבטחה. כלומר, אם הבקשה יכולה לחשוף נתונים ממקור מוצפן למקור לא מוצפן, כמו בבקשות HTTPS ← בקשות HTTP. בקשת HTTP ← HTTP לא מוצפנת לגמרי, ולכן אין שדרוג לאחור. - במקרה שהבקשה היא מאותו מקור, המשמעות היא שהסכימה (HTTPS או HTTP) היא זהה, ולכן אין שדרוג לאחור של האבטחה.
מדיניות ברירת מחדל לגורם מפנה בדפדפנים
נכון לאוקטובר 2021
אם לא הוגדרה מדיניות לגורם מפנה, הדפדפן ישתמש במדיניות ברירת המחדל שלו.
דפדפן | ברירת מחדל של Referrer-Policy / התנהגות |
---|---|
Chrome |
ערך ברירת המחדל הוא strict-origin-when-cross-origin .
|
Firefox |
ערך ברירת המחדל הוא strict-origin-when-cross-origin .החל מגרסה 93, עבור משתמשים עם הגנה מחמירה של מעקב וגלישה פרטית, המערכת מתעלמת מכללי המדיניות הפחות מגבילים לגורם מפנה no-referrer-when-downgrade ,
origin-when-cross-origin ו-unsafe-url
עבור בקשות בין אתרים. כלומר, הגורם המפנה תמיד ייחתך
עבור בקשות בין אתרים, בלי קשר למדיניות של האתר.
|
Edge |
ערך ברירת המחדל הוא strict-origin-when-cross-origin .
|
Safari |
ברירת המחדל דומה ל-strict-origin-when-cross-origin ,
עם כמה הבדלים ספציפיים. לפרטים נוספים, אפשר לעיין במאמר
מניעת מעקב אחר מניעת מעקב.
|
שיטות מומלצות להגדרת המדיניות לגורם מפנה
יש דרכים שונות להגדיר באתר שלכם מדיניות לגורם מפנה:
- ככותרת HTTP
- ב-HTML
- מ-JavaScript על בסיס בקשה
אפשר להגדיר כללי מדיניות שונים לדפים, לבקשות או לרכיבים שונים.
כותרת ה-HTTP והמטא-רכיב הם שניהם ברמת הדף. סדר העדיפות לקביעת המדיניות האפקטיבית של אלמנט הוא:
- מדיניות ברמת הרכיב
- מדיניות ברמת הדף
- ברירת המחדל של הדפדפן
דוגמה:
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />
הבקשה לתמונה היא באמצעות מדיניות no-referrer-when-downgrade
, וכל שאר הבקשות למשאבי משנה מהדף הזה עומדות בדרישות המדיניות strict-origin-when-cross-origin
.
איך להציג את המדיניות לגורם מפנה?
בעזרת securityheaders.com ניתן לקבוע באיזו מדיניות משתמשים באתר או בדף ספציפיים.
אפשר גם להשתמש בכלים למפתחים ב-Chrome, ב-Edge וב-Firefox כדי לראות את המדיניות לגורם מפנה, של בקשה ספציפית. נכון לעכשיו, Safari לא מציג את הכותרת Referrer-Policy
אבל כן מציג את Referer
שנשלח.
![צילום מסך של החלונית 'רשת' של כלי הפיתוח ל-Chrome, עם מדיניות של הגורם המפנה והגורם המפנה.](https://web.dev/static/articles/referrer-best-practices/image/a-screenshot-the-network-7f0db2eae4fd4.jpg?authuser=5&hl=he)
איזו מדיניות כדאי להגדיר לאתר?
אנחנו ממליצים מאוד להגדיר מדיניות לשיפור הפרטיות, כמו strict-origin-when-cross-origin
(או מחמירה יותר).
למה "באופן מפורש"?
אם לא מגדירים מדיניות לגורם מפנה, ייעשה שימוש במדיניות ברירת המחדל של הדפדפן. למעשה, לעיתים קרובות אתרים דוחים את הגדרת ברירת המחדל של הדפדפן. אבל זה לא אידיאלי, כי:
- לדפדפנים שונים יש כללי מדיניות ברירת מחדל שונים, כך שאם מסתמכים על ברירות המחדל של הדפדפן, האתר לא יפעל כצפוי בדפדפנים שונים.
- דפדפנים משתמשים בברירות מחדל מחמירות יותר, כמו
strict-origin-when-cross-origin
ומנגנונים כמו חיתוך של גורמים מפנים לבקשות ממקורות שונים. הצטרפות מפורשת למדיניות לשיפור הפרטיות לפני שינויים בהגדרות ברירת המחדל של הדפדפן נותנת לכם שליטה ועוזרת לכם להריץ בדיקות לפי הצורך.
למה strict-origin-when-cross-origin
(או מחמירה יותר)?
אתם צריכים מדיניות מאובטחת, מועילה ושיפור הפרטיות. המשמעות ה "שימושית" תלויה במה שאתם רוצים מהגורם המפנה:
- מאובטח: במקרה שבאתר שלכם נעשה שימוש ב-HTTPS (אם לא, עליכם להגדיר לו עדיפות), אתם לא רוצים שכתובות ה-URL של האתר ידלפו בבקשות שאינן HTTPS. מאחר שכל אחד ברשת יכול לראות אותן, הדלפות עלולות לחשוף את המשתמשים להתקפות אדם בתווך. כללי המדיניות
no-referrer-when-downgrade
,strict-origin-when-cross-origin
,no-referrer
ו-strict-origin
פותרים את הבעיה הזו. - שיפור הפרטיות: במקרה של בקשה ממקורות שונים,
no-referrer-when-downgrade
משתף את כתובת ה-URL המלאה, וזה עלול לגרום לבעיות פרטיות.strict-origin-when-cross-origin
ו-strict-origin
חולקים רק את המקור, ו-no-referrer
לא משתף שום דבר בכלל. כך נשארות האפשרויותstrict-origin-when-cross-origin
,strict-origin
ו-no-referrer
לשיפור הפרטיות. - שימושי:
no-referrer
ו-strict-origin
אף פעם לא משתפים את כתובת ה-URL המלאה, גם לבקשות מאותו מקור. אם אתם זקוקים לכתובת ה-URL המלאה, עדיף לכםstrict-origin-when-cross-origin
.
כלומר, באופן כללי strict-origin-when-cross-origin
הוא בחירה הגיונית.
דוגמה: הגדרת מדיניות strict-origin-when-cross-origin
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
או בצד השרת, למשל ב-Express:
const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));
מה קורה אם strict-origin-when-cross-origin
(או המחמיר יותר) לא מתאים לכל התרחישים לדוגמה?
במקרה כזה כדאי לנקוט גישה פרוגרסיבית: להגדיר מדיניות הגנה כמו strict-origin-when-cross-origin
לאתר, ואם צריך, מדיניות מתירה יותר עבור בקשות ספציפיות או רכיבי HTML.
דוגמה: מדיניות ברמת הרכיב
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 עשוי להגביל את document.referrer
או את הכותרת Referer
לבקשות של אתרים שונים.
לפרטים.
דוגמה: מדיניות ברמת הבקשה
script.js
:
fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});
מה עוד כדאי לשקול?
המדיניות צריכה להיות תלויה באתר ובתרחישים לדוגמה, כפי שנקבע על ידכם, על ידי הצוות ועל ידי החברה שלכם. אם כתובות URL מסוימות מכילות מידע מזהה או מידע אישי רגיש, עליכם להגדיר מדיניות הגנה.
שיטות מומלצות לטיפול בבקשות נכנסות
לפניכם מספר הנחיות לפעולות שצריך לבצע אם האתר משתמש בכתובת ה-URL המפנה של בקשות נכנסות.
הגנה על נתוני המשתמשים
השדה Referer
יכול להכיל נתונים פרטיים, אישיים או מזהים, לכן חשוב להתייחס אליו בהתאם.
גורמים מפנים נכנסים יכולים לשנות {referer-can-change}
לשימוש בגורם המפנה מבקשות נכנסות ממקורות שונים יש מספר מגבלות:
- אם אין לכם שליטה על ההטמעה של משדר הבקשות, אתם לא יכולים להניח הנחות לגבי הכותרת
Referer
(ו-document.referrer
) שמקבלים. הוא עשוי להחליט לעבור למדיניותno-referrer
בכל שלב , או למדיניות מחמירה יותר מהמדיניות הקודמת. כלומר, מתקבלים פחות נתונים מ-Referer
מאשר בעבר. - דפדפנים משתמשים יותר ויותר במדיניות המפנה
strict-origin-when-cross-origin
כברירת מחדל. כלומר, בבקשות נכנסות ממקורות שונים תוכלו לקבל רק את המקור במקום כתובת URL מלאה של הגורם המפנה, אם באתר השולח לא מוגדרת מדיניות. - דפדפנים עשויים לשנות את אופן הניהול של
Referer
. לדוגמה, חלק ממפתחי הדפדפנים עשויים להחליט לחתוך גורמים מפנים תמיד למקורות בבקשות למשאבי משנה ממקורות שונים, כדי להגן על פרטיות המשתמשים. - יכול להיות שהכותרת
Referer
(ו-document.referrer
) תכיל יותר נתונים ממה שצריך. לדוגמה, יכול להיות שיש לה כתובת URL מלאה אם רוצים לדעת רק אם הבקשה היא ממקורות שונים.
יש חלופות ל-Referer
יכול להיות שתצטרכו לשקול חלופות במקרים הבאים:
- תכונה חיונית באתר משתמשת בכתובת ה-URL המפנה של בקשות נכנסות ממקורות שונים.
- האתר שלכם כבר לא מקבל את החלק מכתובת ה-URL של הגורם המפנה שנדרש לו בבקשה ממקורות שונים. מצב כזה קורה כשהמדיניות של פולט הבקשה משנה את המדיניות, או כשלא מוגדרת מדיניות ברירת המחדל של הדפדפן (למשל, ב-Chrome 85).
כדי להגדיר חלופות, עליך לנתח תחילה באיזה חלק של הגורם המפנה אתם משתמשים.
אם צריך רק את המקור
- אם משתמשים בגורם המפנה בסקריפט שיש לו גישה ברמה העליונה לדף,
window.location.origin
הוא אפשרות חלופית. - אם הן זמינות, כותרות כמו
Origin
ו-Sec-Fetch-Site
מספקות אתOrigin
או מתארות אם הבקשה היא ממקורות שונים, ויכול להיות שזה בדיוק מה שצריך.
אם דרושים רכיבים נוספים של כתובת ה-URL (נתיב, פרמטרים של שאילתה...)
- פרמטרים של בקשה יכולים לטפל בתרחיש לדוגמה, וכך לחסוך את העבודה בניתוח הגורם המפנה.
- אם משתמשים בגורם המפנה בסקריפט שיש לו גישה ברמה העליונה לדף,
window.location.pathname
עשוי לשמש כחלופה. מחלצים רק את קטע הנתיב של כתובת ה-URL ומעבירים אותו כארגומנט, כך שמידע שעשוי להיות רגיש בפרמטרים של כתובת האתר לא יועבר.
אם לא ניתן להשתמש בחלופות האלה:
- בדקו אם אפשר לשנות את המערכות כך שיצפו משדר הבקשות (לדוגמה
site-one.example
) יגדיר במפורש את המידע שדרוש לכם בסוג כלשהו של הגדרה.- יתרונות: יותר מפורש, יותר שמירה על הפרטיות עבור משתמשי
site-one.example
, יותר ביטחון לעתיד. - חסרונות: ייתכן שיותר עבודה בצד שלכם או עבור משתמשי המערכת שלכם.
- יתרונות: יותר מפורש, יותר שמירה על הפרטיות עבור משתמשי
- עליכם לבדוק אם האתר ששולח את הבקשות עשוי להסכים להגדיר מדיניות מפנה של
no-referrer-when-downgrade
לכל רכיב או לפי בקשה.- חסרונות: אפשרות השמירה על הפרטיות עשויה להיות נמוכה יותר אצל משתמשי
site-one.example
, וייתכן שלא תהיה תמיכה בכל הדפדפנים.
- חסרונות: אפשרות השמירה על הפרטיות עשויה להיות נמוכה יותר אצל משתמשי
הגנה על פני זיוף בקשות באתרים שונים (CSRF)
emitter של בקשה תמיד יכול להחליט לא לשלוח את הגורם המפנה על ידי הגדרת
מדיניות no-referrer
, וגורם זדוני יכול אפילו לזייף את הגורם המפנה.
שימוש באסימוני CSRF כהגנה הראשית. כדי להוסיף שכבת הגנה, כדאי להשתמש ב-SameSite, ובמקום ב-Referer
להשתמש בכותרות כמו Origin
(שזמינות בבקשות POST ו-CORS) ו-Sec-Fetch-Site
אם היא זמינה.
רישום ביומן וניפוי באגים
חשוב להגן על מידע אישי או רגיש של המשתמשים, שעשוי להיות ב-Referer
.
אם משתמשים רק במקור, צריך לבדוק אם אפשר להשתמש בכותרת Origin
כחלופה. כך תוכלו לקבל את המידע שנחוץ לכם למטרות ניפוי באגים בצורה פשוטה יותר ובלי לנתח את הגורם המפנה.
תשלומים
ספקי תשלומים עשויים להסתמך על הכותרת Referer
של בקשות נכנסות לבדיקות אבטחה.
למשל:
- המשתמש לוחץ על לחצן קנייה ב-
online-shop.example/cart/checkout
. online-shop.example
מפנה אוטומטית לכתובתpayment-provider.example
כדי לנהל את העסקה.payment-provider.example
בודק אתReferer
של הבקשה הזו מול רשימה של ערכיReferer
מותרים שהוגדרו על ידי המוכרים. אם היא לא תואמת לאף רשומה ברשימה,payment-provider.example
ידחה את הבקשה. אם היא תואמת, המשתמש יכול להמשיך לעסקה.
שיטות מומלצות לבדיקות אבטחה של תזרים תשלומים
כספקי תשלום, אתם יכולים להשתמש ב-Referer
כבדיקה בסיסית מפני התקפות מסוימות. עם זאת, הכותרת Referer
בפני עצמה לא משמשת כבסיס מהימן לבדיקה. באתר ששלח את הבקשה, גם אם מדובר במוכר לגיטימי וגם אם לא, יש אפשרות להגדיר מדיניות no-referrer
שהופכת את המידע על Referer
כך שלא יהיה זמין לספק התשלום.
בדיקה של Referer
עשויה לעזור לספקי תשלומים לתפוס תוקפים תמימים שלא הגדירו מדיניות no-referrer
. אם משתמשים בReferer
כבדיקה ראשונה:
- לא תצפה שה-
Referer
יהיה תמיד קיים. אם הוא קיים, צריך לבדוק אותו רק מול הנתונים המינימליים שהוא יכול לכלול, שהוא המקור.- כשמגדירים את רשימת הערכים המותרים של
Referer
, חשוב לכלול רק את המקור ולא את הנתיב. - לדוגמה, ערכי
Referer
המותרים עבורonline-shop.example
צריכים להיותonline-shop.example
, ולאonline-shop.example/cart/checkout
. כשמצפים לערךReferer
בכלל או לערךReferer
שהוא רק מקור האתר המבקש, אפשר למנוע שגיאות שעשויות לנבוע מהנחות לגביReferrer-Policy
של המוכר.
- כשמגדירים את רשימת הערכים המותרים של
- אם השדה
Referer
חסר, או אם הוא קיים ובדיקת המקור הבסיסית שלReferer
בוצעה בהצלחה, אפשר לעבור לשיטת אימות אחרת ואמינה יותר.
כדי לאמת את התשלומים בצורה אמינה יותר, צריך לאפשר למגיש הבקשה לגבב את הפרמטרים של הבקשה באמצעות מפתח ייחודי. לאחר מכן, ספקי התשלומים יכולים לחשב את אותו גיבוב בצד ולאשר את הבקשה רק אם היא תואמת לחישוב שלכם.
מה קורה לכתובת Referer
כשאתר של מוכר HTTP ללא מדיניות לגורם מפנה מפנה לספק תשלום מסוג HTTPS?
לא מופיע Referer
בבקשה לספק התשלום ב-HTTPS, כי
רוב הדפדפנים משתמשים ב-strict-origin-when-cross-origin
או
no-referrer-when-downgrade
כברירת מחדל כשלאתר לא הוגדרה מדיניות.
המעבר של Chrome למדיניות ברירת מחדל חדשה לא ישנה את ההתנהגות הזו.
סיכום
מדיניות מגן לגורם מפנה היא דרך נהדרת להעניק למשתמשים יותר פרטיות.
למידע נוסף על שיטות שונות להגנה על המשתמשים, כדאי לעיין באוסף בטוחים ומאובטחים
משאבים
- הסבר על "same-site" ו-"same-origin"
- כותרת אבטחה חדשה: מדיניות מפנה (2017)
- מדיניות של גורמים מפנים ב-MDN
- כותרת הגורם המפנה: חששות בנוגע לפרטיות ולאבטחה ב-MDN
- שינוי ב-Chrome: כוונה להבהב כדי להטמיע
- שינוי ב-Chrome: הכוונה בהבהוב
- שינוי ב-Chrome: רשומת סטטוס
- שינוי ב-Chrome: פוסט בבלוג של גרסת בטא 85
- חיתוך של שרשור GitHub באמצעות הגורם המפנה: מה דפדפנים שונים עושים
- מפרט המדיניות של הגורם המפנה
תודה רבה על התוכן והמשוב לכל הבודקים – במיוחד קאסטובהה גובינד, דיוויד ואן קליב, מייק ווסט, סאם דוטון, רוואן מרווד, ג'קסק וקייס באסק.