תאריך פרסום: 23 בספטמבר 2026
אפליקציות אינטרנט מודרניות הופכות מורכבות יותר ויותר, ומשלבות סקריפטים של צד שלישי וקוד שנוצר באופן דינמי מ-AI גנרטיבי. השילובים האלה יכולים להניב תוצאות מרשימות, אבל הם מגבירים באופן משמעותי את הסיכון לזליגת נתונים. כדי לטפל בסיכון הזה, בגרסה 152 של Chrome הוספנו רשימות היתרים לחיבורים – מנגנון אבטחה חדש שמאפשר ליצור ארגז חול קפדני לרשת עבור המסמכים וה-workers.
האתגר של אבטחת התקשורת ברשת
כדי לנהל את התלות ולשמור על הארכיטקטורה של האתר, צריך שליטה מפורשת בנקודות הקצה שהדפים מתקשרים איתן. סקריפטים זדוניים או קוד שנוצר על ידי AI וכולל הזיות יכולים לעקוף בדיקות ברמת האפליקציה כדי לשלוח מידע רגיש לשרתים לא מורשים.
Content Security Policy (CSP) הוא כלי יעיל לשליטה במה שאפשר לטעון ולהפעיל בדף, אבל הוא לא נועד להגביל את המקומות שאליהם הדף מתקשר. CSP מסווג בקשות לסוגים ספציפיים, מה שיוצר רמת פירוט גבוהה מדי כשצריך רק גבול רחב של הרשת. בנוסף, CSP לא מכסה באופן מקיף את כל ממשקי ה-API של פלטפורמת האינטרנט, ומשמיטה מנגנונים כמו שליפה מראש של DNS, ניווטים, WebRTC ועוד.
מהן רשימות היתרים לחיבורים?
רשימות ההיתרים לחיבורים מטפלות בסיכונים האלה בכך שהדפדפן משמש כשומר סף לכל החיבורים לרשת שמקורם בדף. הם מספקים גישה ישירה ויעילה לניהול בקשות רשת מפורשות שמופעלות באמצעות Fetch וממשקי API אחרים של פלטפורמת האינטרנט.
כששולחים כותרת תגובת HTTP Connection-Allowlist, מציינים את תבניות כתובות ה-URL המדויקות שמותרות לכל התקשורת ברשת. כך נאכפת חומת אש ברמת המסגרת שמוגדרת כדחייה כברירת מחדל. לפני יצירת חיבור כלשהו, הדפדפן מאמת את היעד מול הרשימה הלבנה שלכם וחוסם אותו ברמת הרשת אם אין התאמה.
איך משתמשים ברשימות היתרים לחיבורים
המדיניות משתמשת בתחביר הסטנדרטי של URLPattern כדי להגדיר נקודות קצה מותרות. המדיניות הזו נפרדת לכל חלון או הקשר של 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 בלי לחסום את החיבורים. חשוב לוודא שאתם מגדירים גם את Reporting-Endpoints כותרת התגובה של HTTP למיפוי של שם נקודת הקצה שבחרתם לכתובת URL בפועל.
Connection-Allowlist-Report-Only: ("https://trusted.com/*"); report-to=security-endpoint
תרחישי שימוש עיקריים
רשימות ההיתרים לחיבורים מיועדות לסביבות דינמיות או לסביבות שבהן נדרשת רמת אבטחה גבוהה. הם שימושיים במיוחד במקרים הבאים:
- אבטחת AI גנרטיבי: אם אפליקציית האינטרנט שלכם מריצה קוד שנוצר או קוד לא מהימן (כמו ממשקי משתמש שנוצרו על ידי AI או ארגזי חול לפיתוח), אתם יכולים למנוע מהקוד הזה להעביר נתונים לדומיינים חיצוניים.
- פיקוח על צד שלישי: כשמטמיעים סקריפטים או משחקי אינטרנט של צד שלישי, אפשר להבטיח שהם לא ישלחו נתונים לשרתים לא מורשים, גם אם הם ייפרצו.
- אמצעי הגנה ארכיטקטוניים: אתם יכולים לאכוף גבול רשת קפדני סביב חלקים רגישים באפליקציה, כדי להבטיח שהתקשורת תתבצע רק עם השרתים העורפיים שאושרו על ידכם.
אפשר להשתמש בתכונה הזו כשיפור הדרגתי (progressive enhancement) להגדרה קיימת שמבוססת על Content Security Policy (CSP).
בדיקת רשימות ההיתרים לחיבור
התכונה רשימות היתרים לחיבורים זמינה באופן רשמי החל מגרסה 152 של Chrome. כדי להתחיל להגן על אפליקציות האינטרנט שלכם, אתם יכולים להוסיף את הכותרת לתגובות של השרת.
כדי לבדוק את ההגדרה במהלך הפיתוח:
- מגדירים את שרת הפיתוח המקומי לשליחת כותרת תגובת ה-HTTP
Connection-Allowlist. - פותחים את כלי הפיתוח ל-Chrome ובודקים בחלונית Network בקשות שנחסמו, או בכרטיסייה Issues דוחות מפורטים של ניתוח כותרות.