לעיתים קרובות, משאבים בין מקורות שמסופקים על ידי צדדים שלישיים לא כוללים כותרות CORP מתאימות. אם אפשר לבקש אותם בלי פרטי כניסה, עכשיו אפשר לסמן אותם ככאלה כדי להפעיל בידוד בין מקורות (CORS).
השקנו את הערך החדש של מדיניות ה-COEP (מדיניות להטמעה במקורות שונים) credentialless
, שמאפשר לדפדפן לטעון משאבים ממקורות שונים שלא משתמשים במדיניות המשאבים במקורות שונים (CORP), על ידי שליחת בקשה ללא פרטי כניסה, כמו קובצי cookie. כך המפתחים יכולים להשתמש בבידוד בין מקורות בקלות רבה יותר.
למה אנחנו צריכים בידוד ממקורות שונים
חלק מממשקי ה-API באינטרנט מגבירים את הסיכון להתקפות ערוץ צדדי כמו Spectre. כדי לצמצם את הסיכון הזה, הדפדפנים מציעים סביבה מבודדת שמבוססת על הסכמה שנקראת בידוד ממקורות שונים. במצב מבודד בין מקורות, דף האינטרנט יכול להשתמש בתכונות בעלות הרשאות, כולל SharedArrayBuffer
, performance.measureUserAgentSpecificMemory()
ושעונים עם דיוק גבוה ורזולוציה טובה יותר, תוך בידוד המקור מאחרים, אלא אם הם הביעו הסכמה לכך.
דף האינטרנט צריך לשלוח שתי כותרות HTTP כדי לאפשר בידוד בין מקורות:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
במצב של בידוד בין מקורות, כל המשאבים ממקורות שונים חייבים להימסר באמצעות CORS או להגדיר כותרת Cross-Origin-Resource-Policy
לטעינה.
אתגרים בהפעלת בידוד בין מקורות
בידוד בין מקורות (CORS) מעניק לדפי אינטרנט אבטחה טובה יותר ויכולת להפעיל תכונות חזקות, אבל הפריסה שלו קשה. אחד האתגרים הגדולים ביותר הוא הדרישה להפעיל CORS או CORP לכל המשאבים ממקורות שונים. משאבים בלי הכותרות האלה לא ייטענו על ידי הדפדפן בדף מבודד ממקורות שונים.
בדרך כלל, משאבים חוצי-מקורות מוצגים על ידי צדדים שלישיים, שעשוי להיות קשה להם להוסיף את הכותרות הנדרשות.
אבל מה קורה אם אנחנו יודעים שהמשאב בטוח מספיק כדי לטעון אותו? למעשה, המשאבים היחידים שנמצאים בסיכון הם אלה שמתבצעת עבורם בקשה עם פרטי כניסה, כי הם עשויים לכלול מידע רגיש שהתוקף לא יכול לטעון בעצמו. כלומר, משאבים שאפשר לבקש ללא פרטי כניסה זמינים לכולם וניתן לטעון אותם בבטחה.
credentialless
מציל
כאן נכנסת לתמונה COEP: credentialless
. credentialless
הוא ערך חדש לכותרת Cross-Origin-Embedder-Policy
. בדומה ל-require-corp
, אפשר להשתמש בה כדי לאפשר בידוד בין מקורות שונים, אבל במקום לדרוש כותרת CORP:cross-origin
לבקשות ללא CORS ממקורות שונים, הבקשות נשלחות בלי פרטי כניסה (למשל, קובצי cookie).
אפשר להפעיל את הבידוד בין מקורות (CORS) גם באמצעות שתי הכותרות הבאות:
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
כלומר, השרת המבוקש לא יוכל להגיב באמצעות משאב רגיש, ומגיש הבקשה יכול תמיד להניח שהתשובה מכילה רק מידע שזמין באופן ציבורי.
השיטה הזו גם תואמת לתוכנית של הדפדפנים להוצאה משימוש של קובצי Cookie של צד שלישי.
הדגמה (דמו)
אפשר לנסות אפשרויות שונות של כותרות בהדגמה הזו: https://cross-origin-isolation.glitch.me
שאלות נפוצות
האם אפשר לשלוח בקשה עם פרטי כניסה בסביבת credentialless
?
כן, אבל צריך לשנות את המצב של הבקשה כך שתידרש בדיקת CORS בתגובה. בתגי HTML כמו <audio>
, <img>
, <link>
, <script>
ו-<video>
, פשוט מוסיפים את crossorigin="use-credentials"
באופן מפורש כדי להודיע לדפדפן לשלוח בקשות עם פרטי כניסה.
לדוגמה, גם אם למסמך ב-https://www.example.com
יש כותרת Cross-Origin-Embedder-Policy: credentialless
, <img
src="https://images.example.com/avatar.png" crossorigin="use-credentials">
ישלח בקשה עם פרטי כניסה.
בממשק ה-API של fetch()
, אפשר להשתמש ב-request.mode = 'cors'
.
ציינתי COEP: credentialless
, באיזה אופן COEP: require-corp
עדיין שימושי לאתר שלי?
כשמשתמשים ב-COEP: require-corp
, אין צורך להחליף באופן ידני את מצב הבקשה ל-CORS אם נדרשים קובצי cookie לחלק מהמשאבים המשניים שמקורם במקור אחר.
האם אפשר גם לטעון מסגרות iframe ממקורות שונים בלי כותרות מיוחדות בסביבת credentialless
?
לא. כדי לטעון iframes ממקורות שונים בסביבת credentialless
, עדיין נדרשים אותם תנאים כמו בסביבת require-corp
. צריך להציג מסמכי iframe עם שתי כותרות:
Cross-Origin-Embedder-Policy: credentialless
(אוrequire-corp
)Cross-Origin-Resource-Policy: cross-origin
החדשות הטובות הן שיש דיון מתמשך בנושא מתן אפשרות לטעון מסגרות iframe ממקורות שונים ללא הכותרות האלה, על ידי הקצאת crossorigin="anonymous"
למסגרות iframe.
כך תוכלו לטעון מסגרות iframe ממקורות שונים בלי כותרות, אבל בלי פרטי כניסה.
האם דפדפנים אחרים יאמצו את התכונה הזו?
- בעיה במעקב ב-Firefox
- בקשה של Webkit למיקום: No signal
- W3C TAG בקשה למקום: בהמתנה
מה צפוי בהמשך
בקרוב יפורסמו שני עדכונים נוספים כדי לצמצם אתגרים אחרים שקשורים לבידוד בין מקורות:
יכול להיות שמשתמשים שנרשמו לגרסת המקור לניסיון של Chrome כדי להאריך את השינוי של SharedArrayBuffer עקב המכשולים שצוינו למעלה, עשויים לתהות מתי הוא יסתיים. במקור הודענו שהיא תופסק ב-Chrome 96, אבל החלטנו לדחות את זה ל-Chrome 106.
משאבים
- הפיכת האתר ל"מבודד ממקורות שונים" באמצעות COOP ו-COEP
- למה צריך 'מבודד ממקורות שונים' כדי ליהנות מתכונות מתקדמות
- מדריך להפעלת בידוד ממקורות שונים
- עדכוני SharedArrayBuffer ב-Chrome 88 ל-Android וב-Chrome 92 למחשב
תמונה של Martin Adams מ-Unsplash