הסבר על קובצי cookie מסוג SameSite

תמיכה בדפדפנים

  • Chrome: 51.
  • Edge: ‏ 16.
  • Firefox: ‏ 60.
  • Safari: 13.

מקור

כל קובץ cookie מכיל צמד מפתח/ערך יחד עם מספר מאפיינים שקובע מתי ואיפה נעשה בו שימוש.

הוספנו את המאפיין SameSite (הוגדר ב-RFC6265bis) כדי שתוכלו להצהיר אם קובץ ה-cookie מוגבל לדומיין הנוכחי או להקשר של אותו אתר. חשוב להבין מה המשמעות של 'אתר' כאן. האתר הוא השילוב של סיומת הדומיין והחלק של הדומיין שמופיע לפניה. לדוגמה, הדומיין www.web.dev הוא חלק מהאתר web.dev.

מונח מפתח: אם המשתמש נמצא ב-www.web.dev ומבקש תמונה מ-static.web.dev, זוהי בקשה באותו אתר.

רשימת הסיומות הציבוריות קובעת אילו דפים נחשבים כחלק מאותו אתר. הוא לא תלוי רק בדומיינים ברמה העליונה כמו .com, אלא יכול לכלול גם שירותים כמו github.io. כך אפשר לספור את your-project.github.io ואת my-project.github.io כאתרים נפרדים.

מונח מפתח: אם המשתמש נמצא ב-your-project.github.io ומבקש תמונה מ-my-project.github.io, זוהי בקשה באתרים שונים.

שימוש במאפיין SameSite כדי להצהיר על שימוש בקובצי cookie

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

אם מגדירים את SameSite כ-Strict, קובץ ה-cookie יכול להישלח רק בהקשר של צד ראשון, כלומר אם האתר של קובץ ה-cookie תואם לאתר שמוצג בסרגל הכתובות של הדפדפן. לכן, אם קובץ ה-cookie promo_shown מוגדר באופן הבא:

Set-Cookie: promo_shown=1; SameSite=Strict

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

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

<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>

עם קובץ cookie שהוגדר ל-Lax באופן הבא:

Set-Cookie: promo_shown=1; SameSite=Lax

כשהדפדפן מבקש את amazing-cat.png עבור הבלוג של האדם השני, האתר שלכם לא שולח את קובץ ה-cookie. עם זאת, כשהקורא עוקב אחרי הקישור אל cat.html באתר שלכם, הבקשה הזו כוללת את קובץ ה-cookie.

מומלץ להשתמש ב-SameSite באופן הזה, ולהגדיר קובצי cookie שמשפיעים על הצגת האתר כ-Lax, וקובצי cookie שקשורים לפעולות של משתמשים כ-Strict.

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

שלושה קובצי cookie עם התוויות &#39;ללא&#39;, &#39;רופף&#39; או &#39;מחמיר&#39;, בהתאם להקשר שלהם
סימון מפורש של ההקשר של קובץ cookie כ-None,‏ Lax או Strict.

שינויים בהתנהגות ברירת המחדל ללא SameSite

תמיכה בדפדפנים

  • Chrome: ‏ 80.
  • Edge: ‏ 86.
  • Firefox: מאחורי דגל.
  • Safari: לא נתמך.

יש תמיכה רחבה במאפיין SameSite, אבל הוא לא נמצא בשימוש נרחב. בעבר, הגדרת קובצי cookie ללא SameSite גרמה לכך שהם נשלחו כברירת מחדל בכל ההקשרים, מה שחשף את המשתמשים להתקפות CSRF ולדליפה לא מכוונת של מידע. כדי לעודד מפתחים לציין את הכוונה שלהם ולספק למשתמשים חוויה בטוחה יותר, ההצעה של IETF, Incrementally Better Cookies, מציגה שני שינויים מרכזיים:

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

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

SameSite=Lax כברירת מחדל

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

הערך SameSite=None חייב להיות מאובטח

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

Set-Cookie: widget_session=abc123; SameSite=None; Secure

אפשר לבדוק את ההתנהגות הזו החל מגרסה 76 של Chrome על ידי הפעלת about://flags/#cookies-without-same-site-must-be-secure, ומגרסה 69 של Firefox על ידי הגדרת network.cookie.sameSite.noneRequiresSecure בקובץ about:config.

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

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

תודה על התרומות והמשוב של Lily Chen,‏ Malte Ubl,‏ Mike West,‏ Rob Dodson,‏ Tom Steiner ו-Vivek Sekhar.

התמונה הראשית (Hero) של Cookie מאת Pille-Riin Priske ב-Unsplash