מידע נוסף על כותרות שיכולות לשמור על בטיחות האתר שלכם ולאתר במהירות את הפרטים החשובים ביותר.
במאמר הזה מפורטות כותרות האבטחה החשובות ביותר שאפשר להשתמש בהן כדי להגן באתר שלך. אפשר להשתמש בו כדי להבין תכונות אבטחה מבוססות-אינטרנט, להטמיע אותם באתר וכחומר עזר למקרים שבהם תצטרכו לקבל תזכורת.
- כותרות אבטחה מומלצות לאתרים שמטפלים בנתוני משתמשים רגישים:
- Content Security Policy (CSP)
- סוגים מהימנים
- כותרות אבטחה מומלצות לכל האתרים:
- X-Content-Type-Options
- אפשרויות X-Frame
- מדיניות בנושא משאבים ממקורות שונים (CORP)
- מדיניות בנושא פותחנים ממקורות שונים (COOP)
- אבטחת תעבורה מחמירה של HTTP (HSTS)
- כותרות אבטחה לאתרים עם יכולות מתקדמות:
- שיתוף משאבים בין מקורות (CORS)
- מדיניות בנושא הטמעה ממקורות שונים (COEP)
לפני שממשיכים להשתמש בכותרות אבטחה, כדאי להכיר את האיומים הידועים באינטרנט ולמה כדאי להשתמש בכותרות האבטחה האלה.
הגנה על האתר מפני נקודות חולשה בהזרקה
נקודות חולשה בהזרקה מתעוררות כאשר נתונים לא מהימנים מעובדים על ידי יכול להשפיע על ההתנהגות שלו, ובדרך כלל להוביל לביצוע סקריפטים שנשלטים על ידי תוקף. נקודת החולשה הנפוצה ביותר שנגרמה כתוצאה מהחדרה באגים הם בין אתרים שונים scripting (XSS) ב- את צורותיו השונות, כולל השתקפות XSS, XSS של אחסון, מבוסס DOM XSS, וגם וריאציות אחרות.
נקודת חולשה של XSS בדרך כלל יכולה לתת לתוקף גישה מלאה לנתוני משתמש מעובדות על ידי האפליקציה וכל מידע אחר שמתארח באותו אתר origin.
אמצעי ההגנה המסורתיים מפני הזרקות כוללים שימוש עקבי בחטיפת רכב אוטומטית מערכות של תבניות HTML, הנמנעות משימוש בJavaScript מסוכן ממשקי API, ועיבוד תקין של נתוני משתמשים באמצעות אירוח העלאות קבצים בדומיין נפרד וניקוי HTML שבשליטת המשתמשים.
- אפשר להשתמש ב-Content Security Policy (CSP) כדי לקבוע אילו סקריפטים אפשר לשלוח. מופעלת על ידי האפליקציה כדי לצמצם את הסיכון להזרקות.
- להשתמש בסוגים מהימנים כדי לאכוף ניקיון של נתונים שמועברים לגורמים מסוכנים ממשקי API של JavaScript.
- השתמש ב-X-Content-Type-Options כדי למנוע מהדפדפן: תפיסה שגויה של סוגי ה-MIME של משאבי האתר, והדבר עלול להוביל ביצוע הסקריפט.
בידוד האתר מפני אתרים אחרים
הפתיחות של האינטרנט מאפשרת לאתרים לקיים אינטראקציה זה עם זה בדרכים עלול להפר את ציפיות האבטחה של האפליקציה. כולל באופן בלתי צפוי שליחת בקשות מאומתות או הטמעת נתונים מאפליקציה אחרת המסמך של התוקף, וכך מאפשר לו לשנות או לקרוא את נתוני האפליקציה.
נקודות חולשה נפוצות שפוגעות בבידוד של אינטרנט כוללות clickjacking, Cross-site Request Forgery (CSRF), Cross-site הכללת סקריפטים (XSSI), הדלפות בין אתרים.
- השתמש ב-X-Frame-Options כדי למנוע הטמעת מסמכים על ידי אתר זדוני.
- מתבססים על מדיניות בנושא משאבים ממקורות שונים (CORP) כדי למנוע הצגת תכנים באתר מהכללת משאבים באתר ממקורות שונים.
- להשתמש במדיניות בנושא פותחנים ממקורות שונים (COOP) כדי להגן על האתר שלכם חלונות מאינטראקציות על ידי אתרים זדוניים.
- להשתמש בשיתוף משאבים בין מקורות (CORS) כדי לשלוט בגישה למשאבים של האתר ממסמכים ממקורות שונים.
אינטרנט פוסט-ספקטר פיתוח אם הכותרות האלה מעניינות אותך.
בניית אתר חזק באופן מאובטח
Spectre מעביר את כל הנתונים שנטענים
לאותה קבוצת הקשר של גלישה שעלולה להיות קריאה
למרות מדיניות המקור הזהה. דפדפנים מגבילים תכונות
שעשויה לנצל את נקודות החולשה שמאחורי סביבה מיוחדת שנקראת
'cross-origin isolation'. בעזרת בידוד ממקורות שונים, אפשר
להשתמש בתכונות מתקדמות כמו SharedArrayBuffer.
- להשתמש במדיניות כלי הטמעה ממקורות שונים (COEP) יחד עם COOP כדי להפעיל בידוד בין מקורות.
הצפנת התנועה לאתר
בעיות הצפנה מופיעות כאשר האפליקציה לא מצפינה נתונים באופן מלא במעבר, וכך מאפשר לתוקפים מציתות ללמוד על האינטראקציות של המשתמשים עם האפליקציה.
הצפנה לא מספקת עשויה להיווצר במקרים הבאים: אם לא משתמשים ב-HTTPS,
תוכן מעורב, הגדרה של קובצי Cookie ללא Secure
מאפיין
(או __Secure
קידומת),
או אימות CORS מצומצם
בלוגיקה.
- משתמשים ב-HTTP Strict Transport Security (HSTS) כדי לשרת באופן עקבי את דרך HTTPS.
Content Security Policy (CSP)
כתיבת סקריפטים חוצי-אתרים (XSS) היא מתקפה כשנקודת החולשה באתר מאפשרת להחדיר סקריפט זדוני בוצעה.
הספק Content-Security-Policy מספק שכבה נוספת לצמצום התקפות XSS באמצעות
שמגבילות את הסקריפטים שניתן להפעיל בדף.
מומלץ להפעיל מדיניות CSP מחמירה באמצעות אחת מהשיטות הבאות:
- אם אתם מעבדים את דפי ה-HTML בשרת, צריך להשתמש במדיניות CSP מחמירה שאינה מבוססת על קוד סודי.
- אם צריך להציג את קוד ה-HTML באופן סטטי או במטמון, לדוגמה, באפליקציה בעלת דף יחיד, צריך להשתמש במדיניות CSP מחמירה המבוססת על גיבוב.
שימוש לדוגמה: מדיניות CSP שמבוססת על צופן חד-פעמי
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
שימושים מומלצים
1. משתמשים במדיניות CSP מחמירה שלא מבוססת על צופן חד-פעמי (CSP) {: #nonce-based-csp}
אם אתם מעבדים את דפי ה-HTML בשרת, צריך להשתמש במדיניות CSP מחמירה שאינה מבוססת על קוד סודי.
יצירת ערך צופן חדש של סקריפט עבור כל בקשה בצד השרת והגדרת את הכותרת הבאה:
קובץ תצורת שרת
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
ב-HTML, כדי לטעון את הסקריפטים, צריך להגדיר את המאפיין nonce של כל הדפים
<script> תגים לאותה מחרוזת {RANDOM1}.
index.html
<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
// Inline scripts can be used with the <code>nonce</code> attribute.
</script>
Google Photos הוא שירות CSP מחמיר וטוב שמבוסס על צופן חד-פעמי לדוגמה. אפשר להשתמש בכלי הפיתוח כדי לראות איך משתמשים בהם.
2. צריך להשתמש במדיניות CSP מחמירה שמבוססת על גיבוב {: #hash-based-csp}
אם צריך להציג את קוד ה-HTML באופן סטטי או במטמון, לדוגמה, כשבונים אפליקציה בדף יחיד, משתמשים במדיניות CSP מחמירה המבוססת על גיבוב.
קובץ תצורת שרת
Content-Security-Policy:
script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
ב-HTML, עליך להטמיע את הסקריפטים כדי להחיל קוד גיבוב מבוסס כי רוב הדפדפנים לא תומכים בגיבוב חיצוני סקריפטים.
index.html
<script> ...// your script1, inlined </script> <script> ...// your script2, inlined </script>
כדי לטעון סקריפטים חיצוניים, יש לקרוא את המאמר "טעינה דינמית של סקריפטים ממקורות מקור" מתחת אפשרות ב': כותרת תגובה של CSP מבוססת-גיבוב.
הכלי לבדיקת CSP הוא כלי טוב להעריך את מדיניות ה-CSP, אבל במקביל, מוצגת דוגמה טובה ל-CSP מחמירה שלא מבוססת על אף שהיא לא מבוססת. אפשר להשתמש בכלי הפיתוח כדי לראות איך משתמשים בהם.
דפדפנים נתמכים
נקודות נוספות לגבי CSP
frame-ancestorsמגינה על האתר מפני חטיפת קליקים (clickjacking) – סיכון שמתעורר אם מאפשרים על אתרים שאתם לא בטוחים שיטמיעו את שלכם. אם אתם מעדיפים פתרון פשוט יותר, אתם יכולים להשתמשX-Frame-Optionsכדי לחסום את הטעינה, אבלframe-ancestorsנותן הגדרה מתקדמת שמאפשרת לאפשר רק מקורות ספציפיים כמטמיעים.- יכול להיות שהשתמשתם במדיניות CSP כדי לוודא שכל המשאבים באתר נטען באמצעות HTTPS. זה כולל להיות פחות רלוונטיות: בימינו, רוב הדפדפנים חוסמים תוכן מעורב.
- אפשר להגדיר מדיניות CSP גם בדוח בלבד .
- אם אי אפשר להגדיר CSP ככותרת בצד השרת, אפשר גם להגדיר אותו כמטא התיוג. שימו לב שלא ניתן להשתמש במצב דיווח בלבד עבור מטא תגים (אבל השינוי הזה עשוי להשתנות).
מידע נוסף
סוגים מהימנים
מבוסס DOM
XSS הוא
מתקפה שבה נתונים זדוניים מועברים ל-sink שתומך בקוד דינמי
כמו eval() או .innerHTML.
סוגים מהימנים מספקים את הכלים לכתיבה, בדיקת אבטחה ותחזוקה ללא DOM XSS. אפשר להפעיל אותן דרך CSP, קוד JavaScript מאובטח כברירת מחדל על ידי הגבלת ממשקי API מסוכנים באינטרנט לקבל רק אובייקט מיוחד - סוג מהימן.
כדי ליצור את האובייקטים האלה אפשר להגדיר מדיניות אבטחה שלפיה אפשר שכללי אבטחה (כמו בריחה או ניקיון) חלים באופן עקבי לפני שהנתונים נכתבים ב-DOM. לאחר מכן, כללי המדיניות האלה הם המקומות היחידים בקוד שעלול להפעיל DOM XSS.
שימושים לדוגמה
Content-Security-Policy: require-trusted-types-for 'script'
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\</g, '<').replace(/>/g, '>');
}
});
}
// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.
// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped; // '&lt;img src=x onerror=alert(1)&gt;'
שימושים מומלצים
-
אכיפת סוגים מהימנים של sinks מסוכנים ב-DOM הכותרת של CSP ו'סוגים מהימנים':
Content-Security-Policy: require-trusted-types-for 'script'
נכון לעכשיו,
'script'הוא הערך הקביל היחיד עבורrequire-trusted-types-for.כמובן שאפשר לשלב סוגים מהימנים עם הוראות CSP אחרות:
מיזוג מדיניות CSP שמבוססת על צופן חד-פעמי למעלה עם סוגים מהימנים:
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
<aside class="note"><b>הערה: </b> ניתן להגביל את השמות של כללי המדיניות שמותרים עבור סוגים מהימנים על ידי הגדרת <code>סוגים מהימנים</code> נוספים (לדוגמה, <code>trusted-types myPolicy</code>). עם זאת, זו לא דרישה. </aside>
-
הגדרת מדיניות
מדיניות:
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\/g, '>');
}
});
}
-
החלת המדיניות
משתמשים במדיניות כשכותבים נתונים ב-DOM:
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.</p>
<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src="x" onerror="alert(1)">');
el.innerHTML = escaped; // '<img src=x onerror=alert(1)>'
עם require-trusted-types-for 'script', שימוש בסוג מהימן הוא
לדרישה. שימוש ב-DOM API מסוכן עם מחרוזת יוביל
שגיאה.
דפדפנים נתמכים
מידע נוסף
- מניעת נקודות חולשה של סקריפטים חוצי-אתרים מבוססי DOM באמצעות 'מהימנות'
סוגים
- CSP: required-Trust-types-for – HTTP |
MDN
- CSP: סוגים מהימנים – HTTP |
MDN
- הדגמה של סוגים מהימנים – פותחים את 'הכלי לבדיקת כלי הפיתוח' ובודקים
מה קורה
X-Content-Type-Options
כשמוצג מסמך HTML זדוני מהדומיין שלכם (לדוגמה, אם התמונה שהועלתה לשירות תמונות מכילה תגי עיצוב חוקיים של HTML), בדפדפנים מסוימים יתייחס אליו כאל מסמך פעיל ויאפשר לו להריץ סקריפטים של האפליקציה, שמוביל לסקריפט חוצה-אתרים באג.
X-Content-Type-Options: nosniff מונע זאת על ידי הוראה לדפדפן
סוג MIME המוגדר
הכותרת Content-Type לתשובה נתונה נכונה. הכותרת הזו
מומלץ לכל המשאבים שלך.
שימוש לדוגמה
X-Content-Type-Options: nosniff
שימושים מומלצים
מומלץ להשתמש ב-X-Content-Type-Options: nosniff לכל המשאבים המוצגים מ:
השרת שלך וכותרת Content-Type הנכונה.
דוגמאות לכותרות שנשלחו עם קוד HTML של המסמך
X-Content-Type-Options: nosniff Content-Type: text/html; charset=utf-8
דפדפנים נתמכים
מידע נוסף
אפשרויות-X-Frame
אם אתר זדוני יכול להטמיע את האתר שלך כ-iframe, ייתכן תוקפים לגרום למשתמשים לבצע פעולות לא מכוונות clickjacking כמו כן, בחלק כיסויים Spectre-type מתקפות נותנות לאתרים זדוניים, יש הזדמנות ללמוד על התוכן של מסמך מוטמע.
X-Frame-Options מציין אם לדפדפן יש הרשאה לבצע רינדור
דף ב-<frame>, ב-<iframe>, ב-<embed> או ב-<object>. כל המסמכים
מומלץ לשלוח את הכותרת הזו כדי לציין אם הם מאפשרים
שהוטמעו במסמכים אחרים.
שימוש לדוגמה
X-Frame-Options: DENY
שימושים מומלצים
לכל המסמכים שלא מיועדים להטמעה צריך להשתמש בכותרת X-Frame-Options.
כאן ניתן לנסות את האופן שבו התצורות הבאות משפיעות על טעינת iframe
. שינוי X-Frame-Options
בתפריט הנפתח ולוחצים על הלחצן טעינה מחדש של ה-iframe.
הגנה על האתר שלכם מפני הטמעת אתרים אחרים
דחיית ההטמעה של מסמכים אחרים.
X-Frame-Options: DENY
הגנה על האתר מפני הטמעת אתרים ממקורות שונים
אפשר להטמיע קבצים באמצעות מסמכים ממקור זהה בלבד.
X-Frame-Options: SAMEORIGIN
דפדפנים נתמכים
מידע נוסף
מדיניות בנושא משאבים בין מקורות (CORP)
תוקף יכול להטמיע משאבים ממקור אחר, למשל מהאתר שלך, לקבל מידע עליהם באמצעות שימוש באתרים שונים הדלפות.
Cross-Origin-Resource-Policy מצמצם את הסיכון באמצעות ציון של קבוצת
האתרים שהוא יכול להיטען בהם. הכותרת מקבלת אחד משלושה ערכים:
same-origin, same-site וגם cross-origin. כל המשאבים
מומלץ לשלוח את הכותרת הזו כדי לציין אם הן מאפשרות טעינה על ידי
אתרים אחרים.
שימוש לדוגמה
Cross-Origin-Resource-Policy: same-origin
שימושים מומלצים
מומלץ שכל המשאבים יקבלו את אחד מהמשאבים הבאים: שלוש כותרות.
אפשר לנסות את האופן שבו ההגדרות הבאות משפיעות על טעינת משאבים
Cross-Origin-Embedder-Policy: require-corp בסביבה בנושא
להדגמה. משנים את
התפריט הנפתח Cross-Origin-Resource-Policy ולוחצים על טעינה מחדש של
iframe או טען מחדש את התמונה כדי לראות את ההשפעה.
הרשאה לטעינה של משאבים cross-origin
מומלץ ששירותים כמו CDN יחילו את cross-origin על משאבים
(כי הן נטענות בדרך כלל על ידי דפים ממקורות שונים), אלא אם הם כבר מוצגים
דרך CORS, שיש לו השפעה דומה.
Cross-Origin-Resource-Policy: cross-origin
הגבלת משאבים לטעינה מתוך same-origin
צריך להחיל את same-origin על משאבים שמיועדים לטעינה בלבד
לפי דפים מאותו מקור. כדאי להחיל את הכלל הזה על מקורות מידע שיש בהם מידע רגיש
מידע על המשתמש, או תשובות של API שמיועד לקרוא
רק מאותו המקור.
חשוב לזכור שעדיין אפשר לטעון ישירות משאבים עם הכותרת הזו, דוגמה על ידי מעבר לכתובת ה-URL בחלון דפדפן חדש. משאב ממקורות שונים המדיניות מגינה על המשאב רק מפני הטמעה באתרים אחרים.
Cross-Origin-Resource-Policy: same-origin
הגבלת משאבים לטעינה מתוך same-site
מומלץ להחיל את same-site על משאבים שדומים למעלה
אבל הם אמורים להיטען על ידי תת-דומיינים אחרים של האתר.
Cross-Origin-Resource-Policy: same-site
דפדפנים נתמכים
מידע נוסף
מדיניות בנושא פותחנים ממקורות שונים (COOP)
אתר של תוקף יכול לפתוח אתר אחר בחלון קופץ כדי ללמוד מידע על הנושא באמצעות ניצול מבוססי-אינטרנט באתרים שונים הדלפות. במקרים מסוימים, הפעולות האלה עשויות גם לאפשר ניצול לרעה של התקפות ערוץ צדדי על סמך ספקטר.
הכותרת Cross-Origin-Opener-Policy מאפשרת לבודד מסמך
עצמו מחלונות ממקורות שונים שנפתחו דרך window.open() או דרך קישור עם
target="_blank" בלי rel="noopener". כתוצאה מכך, כל מפתח פתיחה חוצה-מקורות
של המסמך לא תהיה הפניה אליו ולא תהיה אפשרות לבצע אינטראקציה
איתו.
שימוש לדוגמה
Cross-Origin-Opener-Policy: same-origin-allow-popups
שימושים מומלצים
אפשר לנסות את האופן שבו ההגדרות הבאות משפיעות על התקשורת עם חלון קופץ ממקורות שונים בהדגמה הזו. שינוי התפריט הנפתח Cross-Origin-Opener-Policy בשני המסמך ובחלון הקופץ, לוחצים על הלחצן Open a חלון קופץ ואז על Send a postMessage כדי לבדוק אם ההודעה באמת נמסרה.
בידוד מסמך מחלונות ממקורות שונים
אם מגדירים same-origin, המסמך יבודד ממקורות אחרים
חלונות של מסמכים.
Cross-Origin-Opener-Policy: same-origin
בידוד מסמך מחלונות ממקורות שונים, אבל הפעלת חלונות קופצים
הגדרה של same-origin-allow-popups מאפשרת למסמך לשמור קובץ עזר אל
את החלונות הקופצים שלו, אלא אם הם הגדירו COOP עם same-origin או
same-origin-allow-popups כלומר, האפליקציה same-origin-allow-popups עדיין יכולה
מגנים על המסמך מפני הפניה כשפותחים אותו כחלון קופץ, אבל
תאפשר לו לתקשר עם חלונות קופצים משלו.
Cross-Origin-Opener-Policy: same-origin-allow-popups
אפשר להפנות למסמך באמצעות חלונות ממקורות שונים
unsafe-none הוא ערך ברירת המחדל, אבל אפשר לציין אותו באופן מפורש
ניתן לפתוח את המסמך באמצעות חלון ממקורות שונים ולשמור על גישה הדדית.
המשמעות של
Cross-Origin-Opener-Policy: unsafe-none
דפוסי הדיווח לא תואמים ל-COOP
אפשר לקבל דוחות כאשר COOP מונע אינטראקציות בין חלונות שונים עם Reporting API.
Cross-Origin-Opener-Policy: same-origin; report-to="coop"
COOP תומכים גם במצב דוחות בלבד, כך שאפשר לקבל דוחות וחוסם בפועל את התקשורת בין מסמכים ממקורות שונים.
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
דפדפנים נתמכים
מידע נוסף
שיתוף משאבים בין מקורות (CORS)
בניגוד לפריטים אחרים במאמר הזה, שיתוף משאבים בין מקורות (CORS) לא אלא מנגנון דפדפן שמבקש ומתיר גישה ממקורות שונים.
כברירת מחדל, דפדפנים אוכפים את מדיניות המקור הזהה כדי למנוע מדף אינטרנט לגשת למשאבים ממקורות שונים. לדוגמה, כאשר תמונה ממקורות שונים נטענת, למרות שהיא מוצגת בדף האינטרנט מבחינה חזותית, ל-JavaScript בדף אין גישה לנתוני התמונה. ספק המשאב יכול להקל את ההגבלות ולאפשר לאתרים אחרים לקרוא הפעלת המשאב באמצעות הפעלת CORS.
שימוש לדוגמה
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
לפני שאתם שוקלים איך להגדיר CORS, כדאי להבין הבחנה בין סוגי הבקשות. בהתאם לפרטי הבקשה, הבקשה להיות מסווגות כבקשה פשוטה או כבקשת קדם-הפעלה.
קריטריונים לבקשה פשוטה:
- השיטה היא
GET,HEADאוPOST. - הכותרות המותאמות אישית כוללות רק את
Accept,Accept-Language,Content-Languageו-Content-Type. - הערך בעמודה
Content-Typeהואapplication/x-www-form-urlencoded,multipart/form-dataאוtext/plain.
כל השאר יסווג כבקשת קדם-הפעלה. לפרטים נוספים, כדאי לקרוא על שיתוף משאבים בין מקורות (CORS) – HTTP | MDN
שימושים מומלצים
בקשה פשוטה
כשבקשה עומדת בקריטריונים של בקשה פשוטה, הדפדפן שולח
בקשה ממקורות שונים עם כותרת Origin שמציינת את הבקשה
המקור.
דוגמה לכותרת בקשה
Get / HTTP/1.1 Origin: https://example.com
דוגמה לכותרת תשובה
Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://example.comמצייןhttps://example.comיכול/ה לגשת לתוכן של התשובה. מקורות המידע להיות קריאה על ידי כל אתר, ניתן להגדיר את הכותרת הזו ל-*. במקרה כזה הדפדפן ידרוש רק לבצע את הבקשה ללא פרטי כניסה לחשבון.Access-Control-Allow-Credentials: trueמציין שהבקשות כוללות פרטי כניסה (קובצי cookie) מורשים לטעון את המשאב. אחרת, בקשות מאומתות יידחו גם אם המקור שממנו נשלחה הבקשה נמצא בכותרתAccess-Control-Allow-Origin.
אפשר לנסות איך הבקשה הפשוטה משפיעה על טעינת משאבים
Cross-Origin-Embedder-Policy: require-corp בסביבה בנושא
להדגמה. לוחצים על
תיבת הסימון שיתוף משאבים בין מקורות ולוחצים על טעינת התמונה מחדש
כדי לראות את האפקט.
בקשות קדם-הפעלה
לפני בקשת קדם-הפעלה מופיעה בקשת OPTIONS לבדוק אם
מותר לשלוח את הבקשה הבאה.
דוגמה לכותרת בקשה
OPTIONS / HTTP/1.1 Origin: https://example.com Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-Type
Access-Control-Request-Method: POSTמאפשר לבצע את הבקשה הבאה באמצעות ה-methodPOST.- הפקודה
Access-Control-Request-Headers: X-PINGOTHER, Content-Typeמאפשרת בקשה להגדיר את כותרות ה-HTTPX-PINGOTHERו-Content-Typeלבקשה הבאה.
דוגמאות לכותרות תגובה
Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-PINGOTHER, Content-Type Access-Control-Max-Age: 86400
Access-Control-Allow-Methods: POST, GET, OPTIONSמציין אפשר לשלוח בקשות באמצעות ה-methodsPOST,GETו-OPTIONS.Access-Control-Allow-Headers: X-PINGOTHER, Content-Typeמציין את הערך הבא הבקשות יכולות לכלול את הכותרותX-PINGOTHERו-Content-Type.Access-Control-Max-Age: 86400מציין שהתוצאה של קדם-ההפעלה אפשר לשמור את הבקשה במטמון למשך 86400 שניות.
דפדפנים נתמכים
מידע נוסף
מדיניות בנושא כלי הטמעה ממקורות שונים (COEP)
כדי לצמצם את היכולת של הכלי מבוסס ספקטר,
מתקפות כדי
גניבת משאבים ממקורות שונים, תכונות כמו SharedArrayBuffer או
כברירת מחדל, performance.measureUserAgentSpecificMemory() מושבתים.
המדיניות Cross-Origin-Embedder-Policy: require-corp מונעת שליחה של מסמכים ועובדים מ-
טעינה של משאבים ממקורות שונים, כמו תמונות, סקריפטים, גיליונות סגנונות, iframes
אחרים, אלא אם המשאבים האלה מסכימים באופן מפורש להיטען דרך CORS
או CORP. אפשר לשלב את COEP עם Cross-Origin-Opener-Policy
כדי לצרף מסמך לבידוד חוצה-מקורות.
כדי להפעיל, צריך להשתמש ב-Cross-Origin-Embedder-Policy: require-corp
בידוד בין מקורות עבור המסמך.
שימוש לדוגמה
Cross-Origin-Embedder-Policy: require-corp
דוגמאות לשימושים
COEP לוקח ערך יחיד של require-corp. שליחת הכותרת הזו מאפשרת
להנחות את הדפדפן לחסום משאבי טעינה שלא הביעו הסכמה דרך
CORS או CORP.
אפשר לנסות את האופן שבו ההגדרות הבאות משפיעות על טעינת המשאבים ב . משנים את בתפריט הנפתח Cross-Origin-Embedder-Policy, התפריט הנפתח Cross-Origin-Resource-Policy, תיבת הסימון דוח בלבד וכו' כדי לבדוק איך הם משפיעים על טעינת משאבים. בנוסף, פותחים את נקודת הקצה לדיווח ההדגמה כדי לבדוק אם המשאבים החסומים דווחו.
הפעלת בידוד ממקורות שונים
הפעלת בידוד בין מקורות על ידי שליחה
Cross-Origin-Embedder-Policy: require-corp עם
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin
דיווח על משאבים שאינם תואמים ל-COEP
אפשר לקבל דוחות על משאבים חסומים שנגרמו על ידי COEP באמצעות הדיווח API.
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"
COEP תומך גם במצב דוח בלבד כך שתוכל לקבל דוחות מבלי ולחסום משאבים בטעינה.
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"
דפדפנים נתמכים
מידע נוסף
HTTP Strict Transport Security (HSTS)
התקשורת בחיבור HTTP פשוט אינה מוצפנת, ולכן הועברו נתונים הנגישים למצותתים ברמת הרשת.
הכותרת Strict-Transport-Security מודיעה לדפדפן שאסור לטעון אף פעם
את האתר באמצעות HTTP ובמקום זאת השתמשו ב-HTTPS. לאחר ההגדרה, הדפדפן ישתמש
HTTPS במקום HTTP
מוגדר בכותרת.
שימוש לדוגמה
Strict-Transport-Security: max-age=31536000
שימושים מומלצים
כל האתרים שעוברים מ-HTTP ל-HTTPS צריכים להגיב עם
הכותרת Strict-Transport-Security כשמתקבלת בקשה עם HTTP.
Strict-Transport-Security: max-age=31536000
דפדפנים נתמכים