למידע נוסף על כותרות שיכולות לשמור על בטיחות האתר ולחפש במהירות את הפרטים החשובים ביותר.
במאמר הזה מפורטות כותרות האבטחה החשובות ביותר שבהן אפשר להשתמש כדי להגן על האתר. תוכלו להיעזר בו כדי להבין תכונות אבטחה מבוססות-אינטרנט, ללמוד איך להטמיע אותן באתר ולהשתמש בו כחומר עזר לתזכורת.
- כותרות אבטחה שמומלצות לאתרים שמטפלים בנתוני משתמשים רגישים:
- מדיניות אבטחת תוכן (CSP)
- סוגים מהימנים
- כותרות אבטחה מומלצות לכל האתרים:
- X-Content-Type-Options
- X-Frame-Options
- מדיניות משאבים ממקורות שונים (CORP)
- מדיניות פותחן מכל מקור (COOP)
- HTTP Strict Transport Security (HSTS)
- כותרות אבטחה לאתרים עם יכולות מתקדמות:
- שיתוף משאבים בין מקורות (CORS)
- מדיניות הטמעה בין מקורות (COEP)
לפני שנכנסים לכותרות של אבטחה, כדאי ללמוד על האיומים המוכרים באינטרנט ולמה כדאי להשתמש בכותרות האבטחה האלה.
הגנה על האתר מפני פרצות של הזרקה
נקודות חולשה בהזרקה נגרמות כשנתונים לא מהימנים שמעובדים על ידי האפליקציה עלולים להשפיע על ההתנהגות שלה, ולרוב הן גורמות להרצת סקריפטים שבשליטת התוקפים. נקודת החולשה הנפוצה ביותר שנגרמת מבאגים בהזרקה היא יצירת סקריפטים חוצי אתרים (XSS) בצורות השונות, כולל XSS, XSS מאוחסנת, XSS שמבוסס על DOM ועוד.
נקודת חולשה של XSS יכולה בדרך כלל לתת לתוקף גישה מלאה לנתוני משתמש שמעובדים על ידי האפליקציה ולכל מידע אחר שמתארח באותו מקור אינטרנט.
אמצעי ההגנה המסורתיים מפני הזרקות כוללים שימוש עקבי במערכות של תבניות HTML, הימנעות משימוש בממשקי API מסוכנים של JavaScript, ועיבוד הולם של נתוני המשתמשים על ידי אירוח העלאות של קבצים בדומיין נפרד וניקוי HTML בשליטת המשתמשים.
- אפשר להשתמש במדיניות אבטחת תוכן (CSP) כדי לקבוע אילו סקריפטים יוכלו להפעיל באפליקציה כדי לצמצם את הסיכון להחדרות.
- משתמשים בסוגים מהימנים כדי לאכוף חיטוי של נתונים שמועברים לממשקי JavaScript מסוכנים.
- כדאי להשתמש ב-X-Content-Type-Options כדי למנוע מהדפדפן לפרש בצורה שגויה את סוגי ה-MIME של משאבי האתר, דבר שעלול להוביל לביצוע של סקריפט.
בודד את האתר שלך מאתרים אחרים
הפתיחות של האינטרנט מאפשרת לאתרים לקיים אינטראקציה זה עם זה בדרכים שיכולות להפר את ציפיות האבטחה של האפליקציות. הפעולות האלה כוללות שליחה בלתי צפויה של בקשות מאומתות או הטמעת נתונים מאפליקציה אחרת במסמך של התוקף, כדי לאפשר לתוקף לשנות או לקרוא את נתוני האפליקציה.
נקודות החולשה הנפוצות שמערערות את בידוד האינטרנט כוללות clickjacking, cross-site request forgery (CSRF), הכללה של סקריפטים חוצי אתרים (XSSI) ודליפות בין אתרים שונים.
- שימוש ב-X-Frame-Options כדי למנוע הטמעה של המסמכים על ידי אתר זדוני.
- אפשר להשתמש במדיניות משאבים ממקורות שונים (CORP) כדי למנוע הכללה של המשאבים באתר על ידי אתר ממקורות שונים.
- אפשר להשתמש במדיניות חוצה מקורות (COOP) כדי להגן על החלונות של האתר שלך מפני אינטראקציות של אתרים זדוניים.
- אפשר להשתמש בשיתוף משאבים בין מקורות (CORS) כדי לשלוט בגישה למשאבים של האתר ממסמכים ממקורות שונים.
כדאי לקרוא את Post-Spectre Web Development אם אתם מתעניינים בכותרות האלה.
בניית אתר מתקדם באופן מאובטח
Spectre מעביר את כל הנתונים שנטענים לאותה קבוצת הקשר גלישה שיכולה להיות קריאה, למרות מדיניות המקור הזהה. דפדפנים מגבילים תכונות שעלולות לנצל את פרצת האבטחה של סביבה מיוחדת שנקראת בידוד בין מקורות. בידוד בין מקורות מאפשר להשתמש בתכונות מתקדמות כמו SharedArrayBuffer
.
- אפשר להשתמש במדיניות כלי הטמעה ממקורות שונים (COEP) בשילוב עם COOP כדי לאפשר בידוד בין מקורות.
הצפנת התנועה אל האתר
בעיות הצפנה מופיעות כשהאפליקציה לא מצפינה נתונים במעבר באופן מלא, וכך מאפשרת לתוקפים לציתות לקבל מידע על האינטראקציות של המשתמשים עם האפליקציה.
הצפנה לא מספיקה עשויה להתרחש במקרים הבאים: כאשר אין שימוש ב-HTTPS,
בתוכן מעורב, בהגדרת קובצי cookie בלי המאפיין Secure
(או בקידומת __Secure
)
או לוגיקת אימות
Lax של CORS.
- משתמשים ב-HTTP Strict Transport Security (HSTS) כדי להציג את התוכן באופן עקבי דרך HTTPS.
Content Security Policy (CSP)
סקריפטים חוצי-אתרים (XSS) הם מתקפה שבה נקודת חולשה באתר מאפשרת להחדיר ולביצוע של סקריפט זדוני.
Content-Security-Policy
מספק שכבה נוספת לצמצום מתקפות XSS על ידי הגבלת הסקריפטים שהדף יכול להפעיל.
מומלץ להפעיל מדיניות CSP מחמירה באחת מהשיטות הבאות:
- אם אתם מעבדים את דפי ה-HTML בשרת, יש להשתמש במדיניות CSP מחמירה שמבוססת על חד-פעמיות.
- אם אתם צריכים להציג את ה-HTML באופן סטטי או במטמון, לדוגמה אם מדובר באפליקציה של דף יחיד, השתמשו ב-CSP מחמיר על בסיס גיבוב.
שימוש לדוגמה: מדיניות CSP חד-פעמית (CSP)
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
שימושים מומלצים
1.
אם אתם מעבדים את דפי ה-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). אפשר להשתמש בכלי הפיתוח כדי לראות איך משתמשים בו.
דפדפנים נתמכים
דברים נוספים שכדאי לדעת לגבי CSP
- ההנחיה
frame-ancestors
מגינה על האתר מפני חטיפת קליקים (clickjacking) – סיכון שנוצר אם מאפשרים לאתרים לא מהימנים להטמיע את האתר שלכם. אם אתם מעדיפים פתרון פשוט יותר, אתם יכולים להשתמש ב-X-Frame-Options
כדי לחסום את הטעינה, אבלframe-ancestors
נותן לכם הגדרה מתקדמת שמאפשרת גישה רק למקורות ספציפיים כרכיבי הטמעה. - יכול להיות שהשתמשתם ב-CSP כדי לוודא שכל המשאבים באתר נטענים ב-HTTPS. זה הפך פחות רלוונטי: נכון לעכשיו, רוב הדפדפנים חוסמים תוכן מעורב.
- אפשר גם להגדיר CSP במצב דוח בלבד.
- אם אי אפשר להגדיר CSP ככותרת בצד השרת, אפשר גם להגדיר אותו כמטא תג. שימו לב שלא ניתן להשתמש במצב דוח בלבד למטא תגים (אם כי עשוי להשתנות).
מידע נוסף
סוגים מהימנים
XSS שמבוססת על DOM היא התקפה שבה נתונים זדוניים מועברים ל-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 ו- Trusted Types:
Content-Security-Policy: require-trusted-types-for 'script'
בשלב הזה,
'script'
הוא הערך הקביל היחיד להוראהrequire-trusted-types-for
.כמובן שאפשר לשלב את 'סוגים מהימנים' עם הנחיות CSP אחרות:
מיזוג 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>trusted-types</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-trusted-types-for – HTTP |
MDN
- CSP: Trusted-types – 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-Options
אם אתר זדוני יכול להטמיע את האתר שלכם כ-iframe, זה עלול לאפשר לתוקפים להפעיל פעולות לא מכוונות על ידי המשתמשים באמצעות clickjacking. בנוסף, במקרים מסוימים, התקפות מסוג Spectre מאפשרות לאתרים זדוניים ללמוד על התוכן של מסמך מוטמע.
X-Frame-Options
מציין אם הדפדפן צריך להיות מורשה לעבד דף ב-<frame>
, ב-<iframe>
, ב-<embed>
או ב-<object>
. מומלץ לשלוח את הכותרת הזו בכל המסמכים כדי לציין אם אפשר להטמיע אותם באמצעות מסמכים אחרים.
שימוש לדוגמה
X-Frame-Options: DENY
שימושים מומלצים
בכל המסמכים שלא מיועדים להטמעה צריך להשתמש בכותרת X-Frame-Options
.
בהדגמה הזו, תוכלו לנסות את ההשפעה של ההגדרות הבאות על טעינת iframe. משנים את התפריט הנפתח X-Frame-Options
ולוחצים על הלחצן Reload the 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 ולוחצים על הלחצן Reload the iframe או Reload the image כדי לראות את ההשפעה.
אישור לטעון משאבים 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)
אתר של תוקף יכול לפתוח אתר אחר בחלון קופץ כדי לקבל מידע עליו, על ידי ניצול דליפות בין אתרים מבוססות-אינטרנט. במקרים מסוימים, זה גם מאפשר לנצל התקפות ערוץ צדדי על בסיס Spectre.
הכותרת 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
. לוחצים על תיבת הסימון
Cross-Origin Resource Share ולוחצים על הלחצן Reload the image
כדי לראות את האפקט.
בקשות קדם-הפעלה
לפני בקשה שמתבצעת מראש מופיעה בקשת 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
מאפשר לבצע את הבקשה הבאה באמצעות השיטהPOST
.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
מציין שאפשר לשלוח בקשות נוספות באמצעות השיטותPOST
,GET
ו-OPTIONS
. Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
מציין שבקשות נוספות יכולות לכלול את הכותרותX-PINGOTHER
ו-Content-Type
.Access-Control-Max-Age: 86400
מציין שאפשר לשמור את התוצאה של הבקשה שמתבצעת לפני ההפעלה במטמון למשך 86,400 שניות.
דפדפנים נתמכים
מידע נוסף
מדיניות הטמעה ממקורות שונים (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-Embedder-Policy, את תיבת הסימון Cross-Origin-Embedder-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 באמצעות Reporting 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
דפדפנים נתמכים