עבור לתוכן
Biscotti CMP
תמחורהורדותמסמכיםMCP Serverבלוג
כניסההתחילו בחינם
בית›בלוג
מה ההבדל בין SessionStorage ל-LocalStorage?טכנולוגיה ומעקב

SessionStorage מול LocalStorage: השלכות פרטיות של ממשקי API לאחסון אינטרנט

7 ביולי 2026 · 17 דקות קריאה

תשובה מהירה: SessionStorage ו-localStorage הם שניהם ממשקי API לאחסון אינטרנט מבוססי דפדפן המאפשרים לאתרים לאחסן נתונים במכשיר של המשתמש, אך הם נבדלים באופן קריטי בעמידותם ובהיקפם. localStorage שומר נתונים ללא הגבלת זמן על פני סשנים וכרטיסיות, בעוד ש-sessionStorage מוחק נתונים כאשר כרטיסיית הדפדפן נסגרת. מנקודת מבט של פרטיות, localStorage טומן בחובו סיכון גבוה משמעותית מכיוון שהנתונים נשארים ללא תפוגה, מה שהופך אותו ליעד אטרקטיבי יותר למעקב, טביעת אצבע ובדיקה רגולטורית תחת מסגרות כמו GDPR.


נקודות מפתח

  • localStorage נשמר ללא הגבלת זמן עד לניקוי מפורש; sessionStorage נמחק כאשר הכרטיסייה או החלון נסגרים.
  • שני סוגי האחסון פגיעים להתקפות XSS (Cross-Site Scripting) ואינם מציעים הצפנה מובנית.
  • נתוני localStorage ו-sessionStorage אינם מועברים לשרת באופן אוטומטי, בניגוד לקובצי Cookie, אך שניהם ניתנים לקריאה מלאה על ידי כל JavaScript הפועל באותו מקור.
  • סקריפטים של צד שלישי הנטענים בדף יכולים לגשת לנתוני localStorage אם הם פועלים באותו הקשר מקור.
  • תחת GDPR, אחסון נתונים לא חיוניים ב-localStorage ללא הסכמת המשתמש מהווה הפרת תאימות, בדומה להטלת קובצי Cookie למעקב.
  • נתונים רגישים כגון אסימוני אימות, סיסמאות ומידע מזהה אישית (PII) לעולם אין לאחסן באף אחד מהמנגנונים ללא שכבות אבטחה נוספות.
  • גלישה פרטית/במצב גלישה בסתר מגבילה את עמידות localStorage אך אינה מבטלת את סיכוני sessionStorage בתוך סשן.
  • מפתחים צריכים להעדיף sessionStorage למצב זמני, סשנים בצד השרת או קובצי Cookie מסוג HttpOnly לאימות, ופלטפורמת ניהול הסכמה כגון Biscotti CMP לניהול הסכמת אחסון.

מה ההבדל בין SessionStorage ל-LocalStorage?

SessionStorage ו-localStorage הם שניהם חלק מממשק ה-API של HTML5 Web Storage, אך הם משרתים מטרות נפרדות המוגדרות על ידי עמידותם והתנהגותם בהיקף הכרטיסייה.

localStorage מאחסן זוגות מפתח-ערך ללא תאריך תפוגה. הנתונים שורדים הפעלות מחדש של הדפדפן, הפעלות מחדש של המערכת ותקופות אי-פעילות בלתי מוגבלות עד שהמשתמש או היישום מסירים אותם במפורש. הם משותפים לכל הכרטיסיות והחלונות הפועלים תחת אותו מקור (פרוטוקול + דומיין + פורט). [1][5]

sessionStorage מאחסן נתונים רק למשך חיי סשן הדף. כאשר המשתמש סוגר את הכרטיסייה או החלון, הנתונים נעלמים. באופן קריטי, כל כרטיסייה שומרת על sessionStorage מבודד משלה, פתיחת אותו URL בכרטיסייה שנייה אינה משתפת את נתוני sessionStorage של הכרטיסייה הראשונה. [1]

תכונה localStorage sessionStorage
עמידות ללא הגבלת זמן רק למשך חיי הכרטיסייה/חלון
משותף בין כרטיסיות כן (אותו מקור) לא (בידוד לכל כרטיסייה)
שורד רענון דף כן כן
שורד סגירת כרטיסייה כן לא
קיבולת אחסון ~5-10 מגה-בייט לכל מקור ~5-10 מגה-בייט לכל מקור
העברה לשרת לא לא
הגנת HttpOnly לא זמינה לא זמינה

שני ממשקי ה-API מצייתים למדיניות אותו מקור, כך שדף בכתובת https://example.com אינו יכול לקרוא אחסון שהוגדר על ידי https://otherdomain.com. [4]

מה ההבדל בין SessionStorage ל-LocalStorage?


האם ל-localStorage יש סיכוני פרטיות בהשוואה ל-sessionStorage?

כן, localStorage טומן בחובו סיכוני פרטיות גבוהים משמעותית מ-sessionStorage, בעיקר בגלל עמידותו הבלתי מוגבלת ונגישותו בין כרטיסיות.

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

גורמי סיכון פרטיות מפתח הייחודיים ל-localStorage:

  • מזהי מעקב עמידים: מזהה ייחודי המאוחסן ב-localStorage יכול לעקוב אחר משתמש על פני מספר ביקורים ללא כל קובץ Cookie בצד השרת.
  • דליפת נתונים בין כרטיסיות: כל סקריפט הפועל בכל כרטיסייה של אותו מקור יכול לקרוא את כל נתוני localStorage.
  • שידור אירועי אחסון: שינויים ב-localStorage מפעילים אירוע storage בכרטיסיות פתוחות אחרות מאותו מקור, מה שמאפשר סנכרון נתונים בין כרטיסיות שהמשתמשים אינם יכולים לצפות בו. [5]
  • אין תפוגה אוטומטית: בניגוד לקובצי Cookie, התומכים בתכונות Max-Age ו-Expires, ל-localStorage אין מנגנון TTL.

האם אתרים יכולים לעקוב אחר משתמשים באמצעות localStorage ו-sessionStorage?

אתרים יכולים ומשתמשים ב-localStorage למעקב מתמשך. sessionStorage פחות שימושי למעקב אך עדיין טומן בחובו סיכוני מעקב בתוך הסשן.

שורה אחת של JavaScript, localStorage.setItem('uid', 'abc123'), יוצרת מזהה מתמשך ששורד ניקוי קובצי Cookie. טכניקה זו, הנקראת לעיתים "evercookie" או "storage-based respawning", תועדה במחקר פרטיות והיא הסיבה לכך שרגולטורים מתייחסים יותר ויותר ל-localStorage תחת אותם כללי הסכמה כמו קובצי Cookie.

sessionStorage יכול לעקוב אחר התנהגות בתוך סשן יחיד (זרימת דף, קלט טפסים, דפוסי ניווט), אך נתונים אלה נעלמים כאשר הכרטיסייה נסגרת, מה שמגביל את שימושיותם לפרופיל ארוך טווח.


כמה זמן נשארים נתונים ב-SessionStorage לעומת LocalStorage?

נתוני localStorage נשארים עד שהם נמחקים במפורש, בין אם על ידי המשתמש המנקה את אחסון הדפדפן, האתר הקורא ל-localStorage.removeItem() או localStorage.clear(), או שהדפדפן אוכף מכסות אחסון. [2]

נתוני sessionStorage נמחקים אוטומטית כאשר הכרטיסייה או החלון שיצרו אותם נסגרים. הם שורדים רענוני דף בתוך אותה כרטיסייה אך אינם מועברים לכרטיסיות חדשות, גם אם המשתמש משכפל את הכרטיסייה בדפדפנים מסוימים. [1]

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


האם SessionStorage פרטי יותר מ-LocalStorage?

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

עם זאת, sessionStorage אינו "פרטי" מטבעו. בתוך סשן פעיל, הוא פגיע באותה מידה להתקפות XSS כמו localStorage. כל סקריפט מוזרק יכול לקרוא ל-sessionStorage.getItem() ולחלץ נתונים בזמן אמת. [3]

בחר sessionStorage אם: הנתונים נחוצים רק לאינטראקציה הנוכחית של המשתמש (לדוגמה, מצב טופס רב-שלבי, אסימוני ניווט חד-פעמיים).

בחר localStorage אם: הנתונים באמת צריכים להישמר על פני סשנים (לדוגמה, העדפות ממשק משתמש, הגדרות לא רגישות), וודא שהם אינם מכילים דבר מזהה אישית.


אילו נתונים אישיים לעולם אין לאחסן ב-localStorage?

הקטגוריות הבאות של נתונים לעולם אין לאחסן ב-localStorage (ויש לטפל בהן בזהירות רבה גם ב-sessionStorage): [3]

  • אסימוני אימות (JWTs, אסימוני OAuth, מזהי סשן)
  • סיסמאות או גיבובי סיסמאות
  • פרטי כרטיס אשראי או תשלום
  • מספרי תעודת זהות ממשלתיים או מספרי ביטוח לאומי
  • שמות מלאים בשילוב עם כתובות דוא"ל או מספרי טלפון
  • רשומות רפואיות או בריאותיות
  • כל נתון המסווג כ"קטגוריה מיוחדת" תחת GDPR (נתונים ביומטריים, נתוני בריאות, דעות פוליטיות)

נתונים המאוחסנים הן ב-localStorage והן ב-sessionStorage אינם מוצפנים כברירת מחדל. כל מי שיש לו גישה פיזית למכשיר, או כל סקריפט המסוגל לבצע פעולה בדף, יכול לקרוא אותם בטקסט רגיל. [3]


האם סקריפטים של צד שלישי יכולים לגשת לנתוני localStorage?

סקריפטים של צד שלישי יכולים לגשת לנתוני localStorage אם הם נטענים ומבוצעים באותו מקור כמו דף המארח. זהו סיכון קריטי ולעיתים קרובות מוערך בחסר.

כאשר אתר משלב סקריפט אנליטיקה או פרסום של צד שלישי באמצעות תג <script>, סקריפט זה פועל בהקשר המקור של דף המארח. הוא יכול לקרוא ולכתוב ל-localStorage של האתר בחופשיות. מדיניות אותו מקור אינה מגנה מפני סקריפטים הנכללים בכוונה או בטעות בדף. [4]

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

זו אחת הסיבות לכך שפלטפורמות לניהול הסכמה חשובות. Biscotti CMP מאפשרת לאתרים לנהל ולתעד את הסכמת המשתמש לפעולות אחסון, כולל מעקב מבוסס localStorage, ובכך מסייעת לאתרים לעמוד בהתחייבויותיהם תחת GDPR ומסגרות דומות.


מהן השלכות ה-GDPR של שימוש ב-localStorage?

תחת GDPR, כל אחסון של נתונים אישיים או מזהי מעקב, ללא קשר למנגנון הטכני, דורש בסיס חוקי. למעקב לא חיוני באמצעות localStorage, בסיס זה הוא כמעט תמיד הסכמת משתמש מפורשת. [2]

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

רשימת בדיקה לתאימות ל-localStorage תחת GDPR:

  • בצע ביקורת על כל מפתחות localStorage שנכתבו על ידי סקריפטים של צד ראשון וצד שלישי.
  • סווג כל מפתח: האם הוא הכרחי לחלוטין לשירות, או שהוא משמש לאנליטיקה/פרסום?
  • לאחסון לא חיוני, הגן על פעולת הכתיבה מאחורי הסכמת משתמש מתועדת.
  • ספק למשתמשים מנגנון ברור למשיכת הסכמה והפעלת מחיקת אחסון.
  • תעד את האינטרס הלגיטימי של בקר הנתונים או את תיעוד ההסכמה.

פלטפורמת ניהול הסכמה מוגדרת כהלכה כגון Biscotti CMP יכולה להפוך חלק גדול ממחזור חיי הסכמה זה לאוטומטי.


האם ניתן לגשת ל-localStorage בין אתרים שונים?

לא. localStorage מוגבל באופן קפדני למקור (שילוב פרוטוקול + דומיין + פורט) שיצר אותו. סקריפט בכתובת https://siteA.com אינו יכול לקרוא נתוני localStorage שהוגדרו על ידי https://siteB.com. [4]

עם זאת, להגנה זו יש מגבלות. אם ספק פרסום או אנליטיקה יחיד טוען את הסקריפטים שלו הן ב-siteA.com והן ב-siteB.com, כל מופע כותב ל-localStorage של האתר המתאים באופן עצמאי. הספק מתאם לאחר מכן את הנתונים בצד השרת, ובכך משיג למעשה מעקב בין אתרים מבלי להפר את מדיניות אותו מקור.


כיצד מצב גלישה בסתר וגלישה פרטית משפיעים על localStorage?

גלישה פרטית/במצב גלישה בסתר יוצרת מחיצת אחסון זמנית הנמחקת כאשר החלון הפרטי נסגר. localStorage שנכתב במהלך סשן גלישה בסתר אינו נשמר בפרופיל הדפדפן הראשי ואינו נגיש לחלונות גלישה רגילים.

sessionStorage מתנהג באופן זהה במצב גלישה בסתר כמו בגלישה רגילה: הוא נמחק כאשר הכרטיסייה נסגרת.

אזהרות חשובות:

  • בתוך סשן גלישה בסתר פעיל, localStorage עדיין ניתן לקריאה על ידי כל הסקריפטים הפועלים באותו הקשר מקור של הסשן.
  • מצב גלישה בסתר אינו מונע חילוץ נתונים מבוסס XSS בזמן אמת.
  • דפדפנים מסוימים מסנכרנים את localStorage בין מכשירים אם המשתמש מחובר לסנכרון הדפדפן, התנהגות שיכולה להעביר נתונים "מקומיים" לתשתית ענן.

כיצד לנקות SessionStorage ו-LocalStorage למען הפרטיות?

ניקוי אחסון הדפדפן פשוט אך דורש פעולה מכוונת מכיוון שהדפדפנים אינם עושים זאת אוטומטית עבור localStorage.

ניקוי ברמת הדפדפן:

  • Chrome: הגדרות > פרטיות ואבטחה > נקה נתוני גלישה > תמונות וקבצים שמורים + נתוני אתר
  • Firefox: הגדרות > פרטיות ואבטחה > קובצי Cookie ונתוני אתר > נקה נתונים
  • Safari: הגדרות > פרטיות > נהל נתוני אתר

ניקוי תכנותי (למפתחים):

  • localStorage.clear() מסיר את כל המפתחות עבור המקור.
  • sessionStorage.clear() מסיר את כל המפתחות עבור סשן הכרטיסייה הנוכחי.
  • localStorage.removeItem('keyName') מסיר מפתח ספציפי.

עבור משתמשי קצה המודאגים ממעקב: ניקוי "נתוני אתר" או "קובצי Cookie ואחסון" בהגדרות הדפדפן מסיר את תוכן localStorage ו-sessionStorage עבור כל האתרים. הרחבות דפדפן המיועדות לפרטיות יכולות להפוך זאת לאוטומטי על בסיס אתר או סשן.


מהן טעויות הפרטיות הנפוצות שמפתחים עושים עם אחסון אינטרנט?

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

  • אחסון JWTs ב-localStorage: אסימוני אימות המאוחסנים ב-localStorage נגישים לכל סקריפט בדף. פגיעות XSS יחידה חושפת את האסימון של כל משתמש. השתמש בקובצי Cookie מסוג HttpOnly עבור אסימוני אימות במקום זאת.
  • אין לוגיקת תפוגה: ל-localStorage אין TTL. מפתחים המאחסנים נתונים ללא בניית לוגיקת תפוגה משאירים נתונים מיושנים ורגישים במכשירים ללא הגבלת זמן.
  • הנחה שאותו מקור פירושו בטוח: מדיניות אותו מקור חוסמת אתרים חיצוניים, לא סקריפטים זדוניים הנטענים מתוך אותו אתר (XSS, ספריות צד שלישי שנפרצו).
  • התעלמות מגישת סקריפטים של צד שלישי: הטמעת סקריפטים של אנליטיקה או פרסומות מבלי לבדוק מה הם קוראים מ-localStorage.
  • אין שער הסכמה לאחסון מעקב: כתיבת מזהי אנליטיקה ל-localStorage לפני קבלת הסכמת המשתמש, הפרה ישירה של GDPR. [2]
  • אחסון PII מיותר: שמירת תגובות API הכוללות פרופילי משתמש מלאים ב-localStorage "לצורך ביצועים" מבלי לשקול את שטח החשיפה.

האם IndexedDB פרטי יותר מ-localStorage?

IndexedDB אינו פרטי יותר מטבעו מ-localStorage. שניהם כפופים למדיניות אותו מקור, שניהם נגישים ל-JavaScript הפועל בדף, ושניהם פגיעים להתקפות XSS.

IndexedDB מציע קיבולת אחסון גדולה יותר ותומך בנתונים מובנים וב-binary blobs, מה שהופך אותו למתאים ליישומים לא מקוונים מורכבים. אך מנקודת מבט של פרטיות ואבטחה, הסיכונים דומים. נתונים המאוחסנים ב-IndexedDB גם אינם מוצפנים כברירת מחדל, והם נשמרים ללא הגבלת זמן אלא אם נמחקים במפורש.

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


מסקנה

הדיון SessionStorage מול LocalStorage: השלכות פרטיות של ממשקי API לאחסון אינטרנט אינו רק הערת שוליים טכנית, יש לו השלכות ישירות על פרטיות המשתמש, תאימות רגולטורית ואבטחת יישומים. עמידותו הבלתי מוגבלת של localStorage ונגישותו בין כרטיסיות הופכות אותו למנגנון אחסון בסיכון גבוה כאשר נעשה בו שימוש לרעה, בעוד שמחיקתו האוטומטית של sessionStorage בסגירת הכרטיסייה הופכת אותו לבחירה הניתנת להגנה יותר למצב זמני.

צעדים הבאים מעשיים למפתחים ובעלי אתרים בשנת 2026:

  1. בצע ביקורת על כל השימוש ב-localStorage וב-sessionStorage על פני סקריפטים של צד ראשון וצד שלישי באמצעות כלי מפתחים של הדפדפן (לשונית Application).
  2. הסר מיד כל אסימוני אימות, PII או מזהים רגישים מאחסון בצד הלקוח.
  3. החלף אחסון אסימוני אימות מבוסס localStorage בקובצי Cookie מסוג HttpOnly, Secure, SameSite המנוהלים בצד השרת.
  4. הטמע זרימת עבודה לניהול הסכמה, באמצעות פלטפורמה כגון Biscotti CMP, כדי להגן על כתיבות localStorage לא חיוניות מאחורי הסכמת משתמש מתועדת.
  5. בנה לוגיקת תפוגה לכל נתוני localStorage שחייבים להישמר, ואכוף ניקוי בהתנתקות.
  6. בצע ביקורת סקריפטים של צד שלישי כדי להבין איזה קוד חיצוני יכול לקרוא מאחסון המקור שלך.
  7. הכשר צוותי פיתוח למניעת XSS כווקטור ההתקפה העיקרי נגד שני סוגי האחסון.

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


שאלות נפוצות

ש: מה ההבדל העיקרי בין sessionStorage ל-localStorage? localStorage שומר נתונים ללא הגבלת זמן על פני סשנים ומשותף לכל הכרטיסיות של אותו מקור. sessionStorage מאחסן נתונים רק למשך חיי הכרטיסייה הנוכחית ונמחק אוטומטית כאשר הכרטיסייה נסגרת.

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

ש: האם sessionStorage בטוח לאחסון סיסמאות? לא. sessionStorage אינו מוצפן ונגיש לכל JavaScript הפועל בדף, כולל סקריפטים זדוניים מוזרקים. לעולם אין לאחסן סיסמאות באף מנגנון אחסון בצד הלקוח.

ש: האם GDPR חל על localStorage? כן. תחת GDPR, אחסון מזהי מעקב או נתונים אישיים ב-localStorage ללא בסיס חוקי, בדרך כלל הסכמת משתמש מפורשת למטרות לא חיוניות, מהווה הפרת תאימות השווה לשימוש בקובצי Cookie ללא הסכמה.

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

ש: האם ניקוי קובצי Cookie מנקה גם את localStorage? לא תמיד. ברוב הדפדפנים, ניקוי "קובצי Cookie" בלבד אינו מנקה את localStorage. משתמשים חייבים לנקות במפורש "נתוני אתר" או "קובצי Cookie ונתוני אתר אחרים" כדי להסיר את תוכן localStorage.

ש: האם מצב גלישה בסתר בטוח מפני מעקב localStorage? מצב גלישה בסתר מונע מנתוני localStorage להישמר לאחר סגירת החלון הפרטי, אך בתוך סשן גלישה בסתר פעיל, localStorage עדיין ניתן לקריאה על ידי כל הסקריפטים בדף.

ש: במה עלי להשתמש במקום localStorage עבור אסימוני אימות? השתמש בקובצי Cookie מסוג HttpOnly, Secure, SameSite המנוהלים בצד השרת. קובצי Cookie אלה אינם נגישים ל-JavaScript, ומבטלים את הסיכון לגניבת אסימונים מבוססת XSS ש-localStorage טומן בחובו.

ש: האם IndexedDB מאובטח יותר מ-localStorage? לא. IndexedDB כפוף לאותן פגיעויות XSS ומדיניות אותו מקור כמו localStorage. הוא מציע קיבולת גדולה יותר ותמיכה במבנה נתונים אך ללא הבטחות פרטיות או אבטחה נוספות.

ש: כמה נתונים יכולים localStorage ו-sessionStorage להכיל? רוב הדפדפנים המודרניים מקצים כ-5 עד 10 מגה-בייט של אחסון לכל מקור עבור כל סוג אחסון, משמעותית יותר ממגבלת 4 קילובייט האופיינית לקובצי Cookie. [2]


הפניות

[1] Sessionstorage - https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage?utm_source=openai

[2] What Is Localstorage Sessionstorage - https://inspectwp.com/en/knowledge-base/what-is-localstorage-sessionstorage?utm_source=openai

[3] Html5 Web Storage Security Risks Safeguarding Localstorage And Sessionstorage - https://www.dopethemes.com/html5-web-storage-security-risks-safeguarding-localstorage-and-sessionstorage/?utm_source=openai

[4] Localstorage - https://javascript.info/localstorage?utm_source=openai

[5] Localstorage Sessionstorage - https://www.w3docs.com/learn-javascript/localstorage-sessionstorage?utm_source=openai

[6] Cookies Vs Localstorage Vs Sessionstorage What Each One Exactly Means - https://www.interserver.net/tips/kb/cookies-vs-localstorage-vs-sessionstorage-what-each-one-exactly-means/?utm_source=openai


מאמרים קשורים

טכנולוגיה ומעקב

Google Consent Mode v2: עדכונים חובה שעליך ליישם עוד היום

Google Consent Mode v2 הוא חובה לאתרי אינטרנט באזור הכלכלי האירופי ובבריטניה. למד מה השתנה, את 4 הפרמטרים הנדרשים, שלבי ההגדרה וכיצד להימנע משיעור השגיאות של 67%.

טכנולוגיה ומעקב

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

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

טכנולוגיה ומעקב

האיום הבלתי נראה של 1x1: הבטחת חוקיות מעקב הפיקסלים שלך

למד כיצד פיקסלי מעקב 1x1 פועלים, מה דורשים GDPR ו-CCPA, וכיצד לבדוק ולחשוף מעקב פיקסלים כדי להישאר תואם לחוק ב-2026.

העמק את הידע שלך

מצא מאמרים מקיפים על כל הנושאים במאגר הידע שלנו.

עבור למאגר הידע

בדיקת עוגיות

בדיקת עוגיות
← חזרה לבלוג
Biscotti CMP

נבנה על ידי Campcruisers GmbH ב-Falkensee, גרמניה.

מוצר

אודותינומאפייניםתמחורתיעודשרת MCPבדיקת עוגיותנגישותהורדותLegal WatchdogAssessment EngineTrust PortalEnterpriseמאגר ידע פרטיות והסכמהבלוגמילון מונחים להסכמת עוגיות ופרטיותתחומי שיפוטנגישות כעקרון עיצובי

משפטי

חותם (Imprint)מדיניות פרטיותתנאי שימושזכות ביטולהסכם עיבוד נתונים (DPA)מדיניות עוגיות

צור קשר

צור קשר
© 2026 Biscotti – שירות של Campcruisers GmbH