טעינת משאבים ממקורות שונים ללא כותרות CORP באמצעות COEP: ללא פרטי כניסה

לעיתים קרובות, משאבים בין מקורות שמסופקים על ידי צדדים שלישיים לא כוללים כותרות CORP מתאימות. אם אפשר לבקש אותם ללא פרטי כניסה, עכשיו אפשר להפעיל בידוד ממקורות שונים על ידי סימון שלהם ככזה.

שלחנו את הערך החדש של מדיניות הטמעה ממקורות שונים (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 או CORP בכל המקורות במשאבי אנוש. משאבים בלי הכותרות האלה לא ייטענו על ידי הדפדפן ב- דף מבודד ממקורות שונים.

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

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

credentialless כדי להציל

כאן COEP: credentialless נכנס. credentialless הוא ערך חדש לכותרת Cross-Origin-Embedder-Policy. בדומה ל-require-corp, אפשר לאפשר בידוד ממקורות שונים, אבל במקום לדרוש CORP:cross-origin עבור בקשות ללא קורות בין מקורות, במקום זאת הן נשלחות ללא פרטי כניסה (למשל, קובצי cookie).

תהיה לך אפשרות להפעיל בידוד ממקורות שונים לחלופין באמצעות שתי הכותרות הבאות:

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?

לא. כדי לטעון מסגרות iframe ממקורות שונים בסביבת credentialless עדיין נדרשים אותם תנאים כמו require-corp. יש להגיש מסמכי iframe עם שתי כותרות:

  • Cross-Origin-Embedder-Policy: credentialless (או require-corp)
  • Cross-Origin-Resource-Policy: cross-origin

החדשות הטובות הן שקיים דיון מתמשך לגבי מתן הרשאה לטעינת מסגרות iframe ממקורות שונים ללא הכותרות האלה על ידי מתן crossorigin="anonymous" לרכיבי iframe. כך תאפשר טעינה של iframes ממקורות שונים ללא כותרות אך ללא כותרות פרטי הכניסה.

האם דפדפנים אחרים יאמצו את התכונה הזו?

מה השלב הבא

יש שני עדכונים נוספים שצפויים בקרוב כדי לצמצם אתגרים אחרים שקשורים בידוד בין מקורות:

אלה שנרשמו לגרסת המקור לניסיון של Chrome כדי להאריך את השינוי של SharedArrayBuffer בגלל המכשולים שלמעלה עשויים לתהות מתי הוא יסתיים. במקור אנחנו הודענו שהוא ייסגר בגרסה 96 של Chrome, אבל החלטנו לדחות את הבקשה ל-Chrome 106.

משאבים

צילום: Martin Adams על ביטול הפתיחה