במאמר הזה מוסבר איך מגדירים קובצי Cookie מהדומיין הנוכחי כדי להבטיח אבטחה, תאימות לדפדפנים שונים ולצמצם את הסיכויים לשיבושים אחרי שיופסק השימוש בקובצי Cookie של צד שלישי.
קובצי cookie יכולים להיות של צד ראשון או של צד שלישי, בהתאם להקשר של המשתמש. בהתאם לאתר שבו המשתמש נמצא באותו זמן. אם הדומיין והסכמה של קובץ ה-Cookie תואמים לדף הנוכחי ברמה העליונה, כלומר מה שמוצג בסרגל הכתובות של הדפדפן, קובץ ה-Cookie נחשב כקובץ Cookie מאותו אתר כמו הדף, ולרוב הוא מכונה קובץ Cookie מהדומיין הנוכחי.
קובצי Cookie מדומיינים שאינם האתר הנוכחי מכונים בדרך כלל קובצי Cookie של צד שלישי.
מתכון טוב לקובצי Cookie מהדומיין הנוכחי
אם קובץ ה-cookie שאתם מגדירים לא נמצא בשימוש באתרים שונים, לדוגמה, הוא משמש לניהול סשנים באתר ואף פעם לא נעשה בו שימוש ב-iframe חוצה-אתרים, קובץ ה-cookie הזה תמיד משמש בהקשר של צד ראשון.
כברירת מחדל, ניתן לשתף קובצי cookie בין אתרים, לגשת אליהם באמצעות JavaScript ולשלוח אותם דרך חיבורי HTTP, שכוללים סיכוני פרטיות ואבטחה מסוימים. אנחנו ממשיכים להשקיע מאמצים כדי לשפר את התנהגות ברירת המחדל, באמצעות ארגז החול לפרטיות והצעות נוספות כמו קובצי cookie שקשורים למקור, אבל אפשר לעשות היום הרבה דברים שאפשר לעשות על ידי הגדרת מאפיינים נוספים לקובצי ה-cookie.
התצורה הבאה היא השיטה המומלצת כדי להבטיח אבטחה ותאימות לדפדפנים שונים לרוב קובצי ה-Cookie מהדומיין הנוכחי. הסינון יספק לך בסיס בטוח, שאותו אפשר לשנות כדי לפתוח הרשאות רק במקרה הצורך. המאמר הזה עוסק גם בווריאציות של מתכונים לתרחישי שימוש ספציפיים.
המתכון
Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;
Host היא תחילית אופציונלית שגורמת לחובה להשתמש במאפיינים מסוימים ומונעת מאפיינים אחרים:
- חובה לכלול את
Secure - חובה להשמיט את
Domain Pathחייב להיות/
אחרי שמוסיפים את Host, אפשר להסתמך על הדפדפן כדי לבדוק אם המאפיינים האלה מוגדרים בהתאם לכללי __Host, ואם לא, ידחה את קובץ ה-cookie.
התכונה Secure מגינה על קובצי cookie מפני גניבה ברשתות לא מאובטחות כי היא מאפשרת לשלוח קובצי cookie רק דרך חיבורי HTTPS. אם לא העברתם את האתר שלכם ל-HTTPS באופן מלא, חשוב לשים לב לכך.
המאפיין Domain מציין אילו מארחים יכולים לקבל קובץ cookie. השמטת קובץ ה-cookie מגבילה את קובץ ה-cookie למארח המסמך הנוכחי, לא כולל תת-דומיינים: קובץ ה-cookie של example.com יישלח בכל בקשה אל example.com אך לא בבקשות ל-images.example.com. אם יש לכם אפליקציות שונות שפועלות בתת-דומיינים שונים, זה מפחית את הסיכון שדומיין אחד שנפגע יוכל להיכנס לכל הדומיינים האחרים.
Path מציין את הנתיב שחייב להימצא בכתובת ה-URL המבוקשת כדי שהדפדפן ישלח את הכותרת Cookie. אם השדה מוגדר ל-Path=/, קובץ ה-cookie יישלח לכל נתיבי כתובות ה-URL בדומיין הזה. השילוב של Domain ו-Path=/ לא גורם לקובץ ה-cookie להיות מקושר למקור ככל האפשר, ולכן הוא פועל באופן דומה לאחסון אחר בצד הלקוח, כמו LocalStorage – אין סיבה לבלבול ש-example.com/a עשוי לקבל ערכים שונים ל-example.com/b.
המאפיין HttpOnly מוסיף הגנה מסוימת מפני סקריפטים זדוניים של צד שלישי באתרים שלכם על ידי הגבלת הגישה ל-JavaScript. הוא מאפשר שליחה של קובץ cookie רק בכותרות של בקשות, ולכן הוא לא זמין ל-JavaScript באמצעות document.cookie.
Max-Age מגביל את חיי קובץ ה-cookie כי סשנים בדפדפן נמשכים זמן רב יחסית, ולא רוצים שקובצי cookie לא פעילים יישארו ללא שינוי. היא מתאימה לקובצי cookie לטווח קצר, כגון פעילויות של משתמשים באתר או פעילויות קצרות יותר, כמו אסימונים לשליחת טפסים. Max-Age מוגדר בשניות, ובדוגמה הקודמת הוא מוגדר ל-7776,000 שניות, כלומר 90 יום. זו ברירת מחדל סבירה, ואפשר לשנות אותה בהתאם לתרחיש לדוגמה שלכם.
ההגדרה SameSite=Lax מגבילה את קובץ ה-cookie כך שיישלח רק בבקשות מאותו אתר. כלומר, במקרים שבהם הבקשה תואמת להקשר הגלישה הנוכחי – האתר ברמה העליונה שהמשתמש מבקר בו כרגע, ומוצג בסרגל המיקום. SameSite=Lax הוא ברירת המחדל בדפדפנים מודרניים, אבל מומלץ לציין תאימות לדפדפנים שונים, עם ברירות מחדל שונות. סימון מפורש של קובץ ה-cookie כקובץ cookie של צד שלישי בלבד מגביל אותו להקשרים של הצד הראשון, ואין צורך לבצע שינויים בקובץ ה-cookie הזה כשקובצי cookie של צד שלישי יוצאים משימוש.
מידע נוסף על מאפיינים שונים של קובצי cookie זמין במסמכי התיעוד בנושא Set-Cookie בנושא MDN.
מתכון של קובצי cookie מהדומיין הנוכחי לאתרים עם תתי-דומיינים
אם יש באתר שלכם תת-דומיינים ואתם רוצים סשן אחד בכולם, הקידומת Host עלולה להיות מגבילה מדי. לדוגמה, news.site יכולים לכלול תתי-דומיינים של נושאים, כמו finance.news.site ו-sport.news.site, וצריך לבחור בכולם סשן אחד של משתמש. במקרה כזה, צריך להשתמש בקידומת __Secure במקום ב-__Host ולציין Domain.
המתכון
Set-Cookie:
__Secure-cookie-name=cookie-value;
Secure;
Domain=news.site;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;
Secure היא קידומת אופציונלית שמחזקת פחות דרישות לגבי Host: רק צריך להגדיר את קובץ ה-cookie באמצעות המאפיין Secure.
הגבלת הגישה לקובצי cookie של צד ראשון בבקשות שנשלחות מאתרים של צד שלישי
קובצי cookie מסוג SameSite=Lax לא נשלחים בבקשות משנה בין אתרים (לדוגמה, כשטוענים תמונות או מסגרות iframe מוטמעים באתר של צד שלישי), אבל הם נשלחים כשמשתמש מנווט לאתר המקור (לדוגמה, אחרי לחיצה על קישור מאתר אחר).
יש לך אפשרות להגביל עוד יותר את הגישה לקובצי cookie ולא לאפשר שליחה שלהם יחד עם בקשות שנשלחות מאתרי צד שלישי באמצעות SameSite=Strict. האפשרות הזו שימושית אם יש לכם קובצי cookie הקשורים לפונקציונליות, שתמיד ישמשו אתכם לאחר ניווט ראשוני, כמו שינוי סיסמה או ביצוע רכישה.
המתכון
Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Strict;