תאריך פרסום: 23 בספטמבר 2026
אפליקציות אינטרנט מודרניות הופכות למורכבות יותר ויותר, ומשלבות סקריפטים של צד שלישי ולפעמים קוד שנוצר באופן דינמי מ-AI גנרטיבי. השילובים האלה יכולים להיות שימושיים מאוד, אבל הם מגדילים באופן משמעותי את הסיכון לזליגת נתונים. כדי לטפל בסיכון הזה, בגרסה 152 של Chrome הוספנו רשימות היתרים לחיבורים – מנגנון אבטחה חדש שמאפשר ליצור ארגז חול קפדני ברשת למסמכים ול-workers.
האתגר באבטחת תקשורת ברשת
אתם צריכים שליטה מפורשת בנקודות הקצה שהדפים שלכם מתקשרים איתן כדי לנהל את יחסי התלות ולאבטח את הארכיטקטורה של האתר. סקריפטים זדוניים או קוד שנוצר על ידי AI עם הזיות יכולים לעקוף את הבדיקות ברמת האפליקציה ולשלוח מידע רגיש לשרתים לא מורשים.
Content Security Policy (CSP) הוא כלי יעיל לשליטה במה שדף יכול לטעון ולהפעיל, אבל הוא לא נועד להגביל את המקומות שאיתם הדף יכול לתקשר. מדיניות CSP מסווגת בקשות לסוגים ספציפיים, מה שיוצר פירוט יתר כשאתם צריכים רק גבולות רשת רחבים. בנוסף, CSP לא מכסה באופן ממצה את כל ממשקי ה-API של פלטפורמת האינטרנט, ומשמיט מנגנונים כמו שליפה מראש של DNS, ניווטים, WebRTC ועוד.
מהן רשימות היתרים של חיבורים?
רשימות היתרים של חיבורים מטפלות בסיכונים האלה בכך שהן הופכות את הדפדפן לשומר הסף של כל החיבורים לרשת שמקורם בדף שלכם. הם מספקים גישה ישירה ופשוטה לניהול בקשות מפורשות לאחזור מהרשת, שמתחילות באמצעות Fetch וממשקי API אחרים של פלטפורמות אינטרנט.
כששולחים כותרת תגובת HTTP מסוג Connection-Allowlist, מציינים את תבניות כתובות ה-URL המדויקות שמותרות לכל התקשורת ברשת. כך אוכפים חומת אש ברמת המסגרת שדוחה כברירת מחדל. לפני יצירת חיבור כלשהו, הדפדפן מאמת את היעד מול רשימת ההיתרים וחוסם אותו ברמת הרשת אם אין התאמה.
איך משתמשים ברשימות היתרים של חיבורים
המדיניות משתמשת בתחביר הסטנדרטי של URLPattern כדי להגדיר נקודות קצה (endpoints) מותרות. המדיניות הזו נפרדת לכל חלון או הקשר של Worker.
הגדרה בסיסית
אתם יכולים להשתמש באסימון response-origin כדי להוסיף באופן דינמי לרשימת ההיתרים את המקור שממנו התגובה נשלחת, לצד נקודות קצה ספציפיות ל-API.
Connection-Allowlist: ("https://api.example.com/*" response-origin)
טיפול בהפניות אוטומטיות וב-WebRTC
כברירת מחדל, רשימות ההיתרים של החיבורים חוסמות את כל ההפניות האוטומטיות וחיבורי ה-WebRTC. אם נאכפת רשימת היתרים, כל בקשה שתוביל להפניה אוטומטית תיחסם, אלא אם תביעו הסכמה מפורשת.
Connection-Allowlist: ("https://api.example.com/*"); redirects=allow; webrtc=allow
דיווח על הפרות
כדי לעקוב אחרי תקלות פוטנציאליות בלי להפריע לשירות, אתם יכולים לפרוס את התכונה במצב דיווח בלבד. הפעולה הזו מנתחת את המדיניות ושולחת דוחות על הפרות לנקודת קצה ל-API מסוימת של Reporting API בלי לחסום את החיבורים. חשוב לוודא שאתם מגדירים גם את כותרת התגובה Reporting-Endpoints ב-HTTP כדי למפות את שם נקודת הקצה שבחרתם לכתובת URL בפועל.
Connection-Allowlist-Report-Only: ("https://trusted.com/*"); report-to=security-endpoint
תרחישי שימוש עיקריים
רשימות היתרים של חיבורים מיועדות לסביבות דינמיות או לסביבות עם רמת אבטחה גבוהה. הם שימושיים במיוחד במקרים הבאים:
- אבטחת AI גנרטיבי: אם אפליקציית האינטרנט שלכם מריצה קוד שנוצר או לא מהימן (כמו ממשקי משתמש שנוצרו על ידי AI או ארגזי חול לפיתוח), אתם יכולים למנוע מהקוד הזה להעביר נתונים לדומיינים חיצוניים.
- פיקוח על צדדים שלישיים: כשמטמיעים סקריפטים או משחקים באינטרנט של צדדים שלישיים, אפשר להבטיח שהם לא ישלחו נתונים לשרתים לא מורשים, גם אם הם נפרצו.
- אמצעי הגנה ארכיטקטוניים: אתם יכולים לאכוף גבולות רשת מחמירים סביב חלקים רגישים באפליקציה, כדי לוודא שהתקשורת מתבצעת רק עם קצוות עורפיים שאושרו.
אפשר להשתמש בתכונה הזו כשיפור הדרגתי (progressive enhancement) להגדרה קיימת שמבוססת על מדיניות אבטחת תוכן (CSP).
רשימות היתרים של חיבורי בדיקה
התכונה "רשימות היתרים של חיבורים" זמינה באופן רשמי החל מגרסה 152 של Chrome. כדי להתחיל להגן על אפליקציות האינטרנט שלכם כבר היום, אתם יכולים להוסיף את הכותרת לתגובות של השרת.
כדי לבדוק את ההגדרות במהלך הפיתוח:
- מגדירים את שרת הפיתוח המקומי כך שישלח את כותרת תגובת ה-HTTP
Connection-Allowlist. - פותחים את כלי הפיתוח ל-Chrome ובודקים בחלונית רשת אם יש בקשות חסומות, או בכרטיסייה בעיות אם יש דוחות מפורטים של ניתוח כותרות.