דף זה תורגם על ידי Cloud Translation API.

מתכונים לקובצי cookie של SameSite

Rowan Merewood

הערה: הדף הזה הוא חלק מסדרה על השינויים במאפיין של קובץ cookie מסוג SameSite, שכוללת:

Chrome, Firefox, Edge, ואחרים משנים את התנהגות ברירת המחדל שלהם בהתאם ל-IETF הצעה, קובצי Cookie טובים יותר באופן מצטבר כך ש:

קובצי cookie ללא מאפיין SameSite נחשבים ל-SameSite=Lax, כלומר, התנהגות ברירת המחדל היא להגביל קובצי Cookie רק לנתונים של צד ראשון להקשרים בלבד.
קובצי Cookie לשימוש באתרים שונים חייבים לציין את הערך SameSite=None; Secure לאפשר הכללה בהקשר של צד שלישי.

אם עדיין לא עשית זאת, עליך לעדכן את המאפיינים של קובצי Cookie של צד שלישי, כדי שהם לא ייחסמו בעתיד.

תמיכה בדפדפן

מקור

תרחישים לדוגמה לקובצי Cookie של אתרים שונים או של צד שלישי

יש כמה תרחישים לדוגמה ודפוסים נפוצים שבהם צריך להפעיל קובצי Cookie שנשלחו בהקשר של צד שלישי. אם תספקו לנו או תלויים באחד מהשימושים האלה במקרים כאלה, ודאו שאתם או הספק מעדכנים את קובצי ה-Cookie שלהם כדי שהשירות יפעל כראוי.

תוכן בתוך `<iframe>`

התוכן מאתר אחר שמוצג ב-<iframe> מופיע אצל צד שלישי הקשר מסוים. התרחישים הרגילים כוללים:

תוכן מוטמע ששותף מאתרים אחרים, כמו סרטונים, מפות, דוגמאות קוד, ופוסטים ברשתות החברתיות.
ווידג'טים משירותים חיצוניים, כמו תשלומים, יומנים, הזמנות לתכונות של הזמנה.
ווידג'טים, כמו לחצנים של רשתות חברתיות או שירותים נגד הונאה, שגורמים בצורה פחות ברורה <iframes>

ניתן להשתמש כאן בקובצי Cookie, בין היתר, כדי לשמור על מצב הסשן, העדפות כלליות, הפעלת נתונים סטטיסטיים או התאמה אישית של תוכן למשתמשים עם חשבונות קיימים.

תרשים של חלון דפדפן שבו כתובת ה-URL של התוכן המוטמע לא תואמת לכתובת ה-URL של הדף. — אם התוכן המוטמע לא מגיע מאותו אתר כמו התוכן ברמה העליונה בהקשר של גלישה, זה תוכן של צד שלישי.

מכיוון שהאינטרנט הוא קומפוזבילי מטבעו, <iframes> משמשים גם להטמעה בתוכן שמוצג ברמה העליונה או בהקשר של צד ראשון. קובצי Cookie מהאתר שמוצגות ב-iframes נחשבים לקובצי cookie של צד שלישי. אם אתם יצירת אתרים שרוצים שאתרים אחרים יטמיעו, וצריכים קובצי cookie כדי ליצור אותם פועלות, צריך גם לוודא שהן מסומנות לשימוש באתרים שונים, או יכול להיעלם באלגנטיות בלעדיהם.

'לא בטוח' בקשות מאתרים שונים

'לא בטוח' אולי נשמע מדאיג כאן, אבל הוא מתייחס לכל בקשה במטרה לשנות מצב. באינטרנט, מדובר בעיקר בבקשות POST. עוגיות מסומנים כSameSite=Lax נשלחים בניווטים בטוחים ברמה העליונה, כמו לחיצה על כדי לעבור לאתר אחר. עם זאת, משהו כמו שליחת <form> אל אתר אחר שמשתמש ב-POST לא כולל קובצי Cookie.

תרשים של בקשה שעוברת מדף אחד לדף אחר. — אם הבקשה הנכנסת משתמשת בערך 'בטוח' , הדף שולח קובצי Cookie.

הדפוס הזה משמש לאתרים שיכולים להפנות את המשתמשים אל שלט רחוק לביצוע פעולה כלשהי לפני חזרה, לדוגמה, הפניה מחדש אל ספק זהויות של צד שלישי. לפני שהמשתמש עוזב את האתר, קובץ cookie מכילה אסימון שימוש יחיד, עם הציפייה שהאסימון הזה יכול להיות בדקנו את הבקשה החוזרת כדי לצמצם cross-Site Request Forgery (CSRF) מתקפות. אם הבקשה החוזרת מגיעה דרך POST, צריך לסמן את קובצי Cookie בתור SameSite=None; Secure.

משאבים מרחוק

כל משאב מרוחק בדף, כמו תגי <img> או תגי <script>, מסתמכים על כך שקובצי Cookie נשלחים יחד עם בקשה. תרחישים נפוצים לדוגמה כוללים: פיקסלים למעקב והתאמה אישית של התוכן.

הכלל הזה חל גם על בקשות שנשלחות מ-JavaScript באמצעות fetch או XMLHttpRequest. אם מתבצעת קריאה אל fetch() עם אפשרות credentials: 'include', סביר להניח שהבקשות האלה יכללו קובצי Cookie. ב-XMLHttpRequest, קובצי cookie צפויים מסומנים בדרך כלל באמצעות ערך withCredentials של true. קובצי ה-cookie האלה צריכים להיות מסומנים כראוי כדי להיכלל ב- בין אתרים.

תוכן בתוך WebView

WebView באפליקציה ספציפית לפלטפורמה מופעלת באמצעות דפדפן. המפתחים צריכים לבדוק אם ההגבלות או הבעיות שמשפיעות על האפליקציות שלהם חלות גם על את רכיבי ה-WebView של האפליקציה.

Android גם מאפשרת לאפליקציות ספציפיות לפלטפורמה להגדיר קובצי Cookie ישירות באמצעות CookieManager API. בדומה לקובצי cookie שמוגדרים באמצעות כותרות או JavaScript, מומלץ לכלול SameSite=None; Secure אם הן מיועדות לשימוש באתרים שונים.

איך מטמיעים את `SameSite` עוד היום

יש לסמן את כל קובצי ה-cookie שנחוצים רק בהקשר של צד ראשון כ-SameSite=Lax או SameSite=Strict, בהתאם לצרכים שלך. אם לא תסמנו את קובצי ה-Cookie האלה ובמקום זאת מסתמכים על התנהגות ברירת המחדל של הדפדפן כדי לטפל בהם, הם יכולים לפעול באופן לא עקבי בדפדפנים, ועלולה להפעיל אזהרות במסוף לגבי כל אחד מהדפדפנים .

Set-Cookie: first_party_var=value; SameSite=Lax

חשוב לסמן את כל קובצי ה-Cookie שנדרשים בהקשר של צד שלישי בתור SameSite=None; Secure שני המאפיינים נדרשים. אם רק מציינים None בלי Secure, קובץ ה-cookie יידחה. כדי להביא בחשבון את ההבדלים בהטמעות של הדפדפן, ייתכן שתצטרכו להשתמש בחלק האסטרטגיות שמתוארות במאמר טיפול בלקוחות לא תואמים.

Set-Cookie: third_party_var=value; SameSite=None; Secure

טיפול בלקוחות לא תואמים

כי השינויים האלה כוללים את None ואת התנהגות ברירת המחדל עדיין חדשים יחסית, בדפדפנים שונים מטפלים בהם בדרכים שונות. אפשר להפנות אל דף העדכונים ב-chromium.org לרשימה של בעיות ידועות, אבל ייתכן שזוהי רשימה חלקית בלבד.

אחת מהדרכים לעקוף את הבעיה היא להגדיר כל קובץ cookie גם בסגנון החדש וגם בסגנון הישן:

Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure

דפדפנים שמיישמים את ההתנהגות החדשה יותר מגדירים את קובץ ה-cookie עם הערך SameSite עם ערך מסוים. דפדפנים שלא מטמיעים את ההתנהגות החדשה מתעלמים מהערך הזה ומגדירים קובץ ה-cookie 3pcookie-legacy. במהלך העיבוד של קובצי cookie כלולים, האתר לבדוק קודם את הנוכחות של הסגנון החדש של קובצי cookie, ואז לחזור את קובץ ה-cookie מדור קודם, אם הוא לא מצליח למצוא קובץ חדש.

הדוגמה הבאה מראה איך לעשות זאת ב-Node.js באמצעות Express framework תווכה של cookie-parser:

const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());

app.get('/set', (req, res) => {
  // Set the new style cookie
  res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
  // And set the same value in the legacy cookie
  res.cookie('3pcookie-legacy', 'value', { secure: true });
  res.end();
});

app.get('/', (req, res) => {
  let cookieVal = null;

  if (req.cookies['3pcookie']) {
    // check the new style cookie first
    cookieVal = req.cookies['3pcookie'];
  } else if (req.cookies['3pcookie-legacy']) {
    // otherwise fall back to the legacy cookie
    cookieVal = req.cookies['3pcookie-legacy'];
  }

  res.end();
});

app.listen(process.env.PORT);

בגישה הזו אתם נדרשים להשקיע יותר מאמץ, להגדיר קובצי Cookie מיותרים משתנה בשלב ההגדרה וגם בתהליך הקריאה של קובץ ה-cookie. עם זאת, כדאי מכסים את כל הדפדפנים ללא קשר להתנהגות שלהם, ושומרים קובצי cookie של צד שלישי פועלות.

במקום זאת, אתם יכולים לזהות את הלקוח באמצעות המחרוזת של סוכן המשתמש כאשר הכותרת Set-Cookie נשלחה. עיינו ב רשימה של לקוחות שאינם תואמים, ולהשתמש בספריית זיהוי של סוכן משתמש שמתאימה לפלטפורמה, לדוגמה, הספרייה ua-parser-js ב-Node.js. בשיטה הזו צריך לבצע רק שינוי אחד, אבל באמצעות סוכן משתמש יכול להיות שסחיטה לא תאתר את כל המשתמשים שהושפעו.

תמיכה ב-`SameSite=None` בשפות, בספריות וב-frameworks

רוב השפות והספריות תומכות במאפיין SameSite בשביל קובצי Cookie. עם זאת, מכיוון שההוספה של SameSite=None עדיין יחסית לאחרונה, ייתכן שבשלב הזה תצטרכו לעקוף התנהגות רגילה. ההתנהגויות האלה מתועדות מאגר SameSite דוגמאות ב-GitHub.

קבלת עזרה

קובצי ה-cookie משמשים בכל מקום באינטרנט, והם נדירים אצל כל צוות פיתוח להיות בעלי ידע מלא על המקומות שבהם האתר מגדיר אותם ומשתמש בהם, במיוחד בתרחישים לדוגמה בין אתרים שונים. אם נתקלים בבעיה, יכול להיות שזו הפעם הראשונה מישהו נתקל בזה, אז אתם מוזמנים לפנות אלינו:

להעלות בעיה ב מאגר SameSite דוגמאות ב-GitHub.
אפשר לשאול שאלה "samesite" ב-StackOverflow.
במקרה של בעיות בהתנהגות של Chromium, אפשר לדווח על באג מעקב אחר בעיות ב-Chromium
מעקב אחר ההתקדמות של Chrome דף העדכונים של SameSite.