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

תמיכה בדפדפן

  • 51
  • 16
  • 60
  • 13

מקור

כל קובץ cookie מכיל צמד מפתח/ערך יחד עם מספר מאפיינים שקובעים מתי ואיפה ייעשה שימוש בקובץ ה-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

תמיכה בדפדפן

  • 80
  • 86
  • x

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

  • קובצי 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

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

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

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

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

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