הסבר מהיר על כותרות אבטחה

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

Eiji Kitamura

Artur Janc

Maud Nalpas

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

כותרות אבטחה מומלצות לאתרים שמטפלים בנתונים רגישים של משתמשים:

Content Security Policy‏ (CSP)

Trusted Types

כותרות אבטחה מומלצות לכל האתרים:

X-Content-Type-Options

X-Frame-Options

Cross-Origin Resource Policy (CORP)

Cross-Origin Opener Policy (COOP)

HTTP Strict Transport Security (HSTS)

כותרות אבטחה לאתרים עם יכולות מתקדמות:

שיתוף משאבים בין מקורות (CORS)

מדיניות כלי להטמעה ממקורות מרובים (COEP)

איומים מוכרים באינטרנט

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

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

הגנה על האתר מפני נקודות חולשה של הזרקה

נקודות חולשה בהזרקה נוצרות כשנתונים לא מהימנים שמעובדים על ידי האפליקציה עשויים להשפיע על ההתנהגות שלה, ובדרך כלל מובילים להפעלה של סקריפטים שנשלטים על ידי תוקף. נקודת החולשה הנפוצה ביותר שנגרמת על ידי באגים בהחדרה היא פריצה מסוג XSS (cross-site scripting) (XSS) בצורות השונות שלה, כולל פריצה מסוג XSS משתקפת, פריצה מסוג XSS מאוחסנת, פריצה מסוג XSS מבוססת-DOM וריאנטים אחרים.

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

אמצעי ההגנה המסורתיים מפני הזרקות כוללים שימוש עקבי במערכות של תבניות HTML עם בריחה אוטומטית (autoescaping), הימנעות משימוש בממשקי API מסוכנים של JavaScript ועיבוד תקין של נתוני משתמשים על ידי אירוח העלאות של קבצים בדומיין נפרד וסינון של HTML בשליטת משתמשים.

• כדי לצמצם את הסיכון להזרקות, אפשר להשתמש במדיניות אבטחת תוכן (CSP) כדי לקבוע אילו סקריפטים האפליקציה יכולה להריץ.
• משתמשים בסוגים מהימנים כדי לאכוף סניטציה של נתונים שמועברים לממשקי API מסוכנים של JavaScript.
• משתמשים ב-X-Content-Type-Options כדי למנוע מהדפדפן לפרש בטעות את סוגי ה-MIME של משאבי האתר, ומצב כזה עלול להוביל להפעלת הסקריפט.

בידוד האתר מאתרים אחרים

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

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

• משתמשים ב-X-Frame-Options כדי למנוע הטמעת מסמכים על ידי אתר זדוני.
• משתמשים במדיניות משאבים בין מקורות (CORP) כדי למנוע מאתר ממקור אחר לכלול את המשאבים של האתר שלכם.
• משתמשים במדיניות 'פותחן בין מקורות' (COOP) כדי להגן על החלונות של האתר מפני אינטראקציות עם אתרים זדוניים.
• משתמשים בשיתוף משאבים בין מקורות (CORS) כדי לשלוט בגישה למשאבים של האתר ממסמכים ממקורות שונים.

אם הנושא הזה מעניין אתכם, כדאי לקרוא את המאמר Post-Spectre Web Development.

בניית אתר חזק באופן מאובטח

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

• משתמשים במדיניות כלי להטמעה ממקורות מרובים (COEP) יחד עם COOP כדי להפעיל בידוד בין מקורות שונים.

הצפנת התנועה לאתר

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

הצפנה לא מספיקה יכולה לקרות במקרים הבאים: שימוש ב-HTTPS, תוכן מעורב, הגדרה של קובצי cookie ללא Secure המאפיין (או __Secure הקידומת), או לוגיקה לוגית של אימות CORS.

• משתמשים ב-HTTP Strict Transport Security ‏(HSTS) כדי להציג את התוכן שלכם באופן עקבי דרך HTTPS.

Content Security Policy (CSP)

פרצת אבטחה XSS‏ (cross-site scripting) היא מתקפה שבה נקודת חולשה באתר מאפשרת להחדיר סקריפט זדוני ולהריץ אותו.

Content-Security-Policy מספק שכבה נוספת כדי לצמצם את מתקפות ה-XSS על ידי הגבלת הסקריפטים שאפשר להריץ בדף.

מומלץ להפעיל CSP מחמיר באחת מהגישות הבאות:

• אם אתם מבצעים עיבוד של דפי ה-HTML בשרת, השתמשו ב-CSP מחמיר שמבוסס על nonce.
• אם צריך להציג את ה-HTML באופן סטטי או לשמור אותו במטמון, למשל אם מדובר באפליקציה של דף יחיד, צריך להשתמש ב-CSP קפדני שמבוסס על גיבוב (hash).

דוגמה לשימוש: CSP שמבוסס על nonce

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

איך משתמשים ב-CSP

שימושים מומלצים

הערה: מדיניות CSP יכולה לשמש כהגנה נוספת מפני התקפות XSS. עדיין צריך לסמן בתו בריחה (escape) את הקלט של המשתמשים.

1. שימוש ב-CSP מחמיר שמבוסס על nonce {: #nonce-based-csp}

אם אתם מבצעים עיבוד של דפי ה-HTML בשרת, השתמשו ב-CSP מחמיר שמבוסס על nonce.

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

יוצרים ערך nonce חדש של סקריפט לכל בקשה בצד השרת ומגדירים את הכותרת הבאה:

קובץ תצורה של שרת

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 מחמיר שמבוסס על nonce. אתם יכולים להשתמש בכלי הפיתוח כדי לראות איך הוא משמש.

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 Evaluator הוא כלי טוב להערכת ה-CSP, אבל הוא גם דוגמה טובה ל-CSP מחמיר שמבוסס על nonce. אפשר להשתמש בכלי הפיתוח כדי לראות איך משתמשים בהם.

דפדפנים נתמכים

* https: הוא חלופה ל-Safari ו-unsafe-inline הוא חלופה לגרסאות ישנות מאוד של דפדפן. https: ו-unsafe-inline לא מפחיתים את רמת הבטיחות של המדיניות, כי דפדפנים שתומכים ב-strict-dynamic יתעלמו מהם. מידע נוסף זמין במאמר הוספת חלופות לתמיכה ב-Safari ובדפדפנים ישנים יותר. * עדיין אין תמיכה ב-strict-dynamic ב-Safari. עם זאת, מדיניות CSP מחמירה, כמו בדוגמאות שלמעלה, בטוחה יותר מ-CSP ברשימת ההיתרים (ובטוחה בהרבה מ-CSP בכלל) לכל המשתמשים שלכם. גם ב-Safari, מדיניות CSP מחמירה מגינה על האתר מפני סוגים מסוימים של התקפות XSS, כי נוכחות ה-CSP אוסרת להשתמש בתבניות לא בטוחות מסוימות.

דברים נוספים שכדאי לדעת על CSP

• ההנחיה frame-ancestors מגינה על האתר מפני clickjacking – סיכון שנוצר אם מאפשרים לאתרים לא מהימנים להטמיע את האתר שלכם. אם אתם מעדיפים פתרון פשוט יותר, תוכלו להשתמש ב-X-Frame-Options כדי לחסום את הטעינה, אבל frame-ancestors מאפשר לכם להגדיר באופן מתקדם ולאפשר רק מקורות ספציפיים להטמעה.
• יכול להיות שהשתמשתם ב-CSP כדי לוודא שכל משאבי האתר נטענים דרך HTTPS. הנושא הזה הפך לפחות רלוונטי: כיום רוב הדפדפנים חוסמים תוכן מעורב.
• אפשר גם להגדיר CSP במצב דוח בלבד.
• אם אתם לא יכולים להגדיר מדיניות CSP ככותרת בצד השרת, אתם יכולים להגדיר אותה גם בתור מטא תג. חשוב לדעת: אי אפשר להשתמש במצב דוח בלבד למטא תגים (אבל יכול להיות שהמצב הזה ישתנה).

מידע נוסף

• צמצום היקף ה-XSS באמצעות מדיניות אבטחת תוכן (CSP) מחמירה
• קיצורי דרך בנושא מדיניות אבטחת תוכן

סוגים מהימנים

XSS מבוסס-DOM הוא התקפה שבה נתונים זדוניים מועברים לבור שמאפשר הפעלת קוד דינמי, כמו eval() או .innerHTML.

Trusted Types מספקים את הכלים לכתיבה, לבדיקת אבטחה ולתחזוקה של אפליקציות ללא 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, '&lt;').replace(/>/g, '&gt;');
    }
  });
}

// 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;  // '<img src=x onerror=alert(1)>'

איך להשתמש בסוגים מהימנים

שימושים מומלצים

1. אכיפה של סוגים מהימנים למקורות DOM מסוכנים כותרת CSP ו-Trusted Types:

   Content-Security-Policy: require-trusted-types-for 'script'

   בשלב זה, 'script' הוא הערך היחיד הקביל להנחיה require-trusted-types-for.

   כמובן, אפשר לשלב בין Trusted Types להנחיות אחרות של CSP:

מיזוג של CSP מבוסס-nonce מהקודם עם Trusted Types:

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> אפשר להגביל את שמות כללי המדיניות של Trusted Types על ידי הגדרת הוראה נוספת של <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, '>');
    }
  });
}
    
הערה:  אפשר להגדיר כללי מדיניות עם שמות שרירותיים, אלא אם מגבילים את השמות של כללי המדיניות המותרים מסוג Trusted Types על ידי הגדרת ההנחיה trusted-types. 
  
  

    
החלת המדיניות
    
שימוש במדיניות בזמן כתיבת נתונים ל-DOM:
    
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;
    
כשמשתמשים ב-require-trusted-types-for 'script', חובה להשתמש בסוג מהימן. שימוש בכל ממשק API מסוכן של DOM עם מחרוזת יוביל לשגיאה.
  

דפדפנים נתמכים

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  
מידע נוסף

  
מניעת נקודות חולשה של סקריפטים חוצי-אתרים מבוססי DOM באמצעות סוגים מהימנים
  
CSP: require-trusted-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

שימושים מומלצים

מומלץ להשתמש ב-X-Content-Type-Options: nosniff לכל המשאבים שנשלחים מהשרת עם הכותרת הנכונה מסוג Content-Type.

דוגמה לכותרות שנשלחות עם HTML של מסמך

X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

דפדפנים נתמכים

תמיכה בדפדפן

• 64
• 12
• 50
• 11

מקור

מידע נוסף

• X-Content-Type-Options – HTTP MDN

X-Frame-Options

אם אתר זדוני יכול להטמיע את האתר שלכם כ-iframe, הדבר עלול לאפשר לתוקפים לגרום למשתמשים לבצע פעולות לא מכוונות באמצעות הונאת clickjacking. בנוסף, במקרים מסוימים התקפות מסוג Spectre מאפשרות לאתרים זדוניים לקבל מידע על התוכן של מסמך מוטמע.

השדה X-Frame-Options מציין אם הדפדפן יכול להציג דף ב-<frame>, ב-<iframe>, ב-<embed> או ב-<object>. מומלץ לשלוח את הכותרת הזו בכל המסמכים כדי לציין אם אפשר להטמיע אותם במסמכים אחרים.

הערה: אם אתם צריכים שליטה פרטנית יותר, למשל לאפשר רק למקור ספציפי להטמיע את המסמך, השתמשו בהוראה frame-ancestors של CSP.

דוגמה לשימוש

X-Frame-Options: DENY

איך משתמשים ב-X-Frame-Options

שימושים מומלצים

לכל המסמכים שלא מיועדים להטמעה צריך להשתמש בכותרת X-Frame-Options.

בהדגמה הזו תוכלו לנסות את האופן שבו ההגדרות הבאות משפיעות על טעינת iframe. משנים את התפריט הנפתח X-Frame-Options ולוחצים על הלחצן טעינה מחדש של ה-iframe.

הגנה על האתר מפני הטמעה על ידי אתרים אחרים

דחיית ההטמעה של מסמכים אחרים.

X-Frame-Options: DENY

הגנה על האתר מפני הטמעה על ידי אתרים מקור שונים

מתן הרשאה להטמעה רק על ידי מסמכים מאותו מקור.

X-Frame-Options: SAMEORIGIN

אם המסמכים ניתנים להטמעה כברירת מחדל, מפתחי האתר צריכים לשלוח את הערך DENY או SAMEORIGIN באופן מפורש כדי להפסיק את ההטמעה ולהגן על עצמם מפני התקפות בערוץ צדדי. צוות Chrome שוקל לעבור לחסימת הטמעת מסמכים כברירת מחדל, כדי שהאתרים יהיו מאובטחים גם אם לא מגדירים את הכותרת באופן מפורש. בעולם החדש הזה, יהיה צורך להביע הסכמה מפורשת להטמעת מסמכים.

דפדפנים נתמכים

תמיכה בדפדפן

• 4
• 12
• 4
• 4

מקור

מידע נוסף

• X-Frame-Options – HTTP

מדיניות משאבים ממקורות שונים (CORP)

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

כדי לצמצם את הסיכון הזה, Cross-Origin-Resource-Policy מציין את קבוצת האתרים שמהם אפשר לטעון אותו. הכותרת מקבלת אחד משלושה ערכים: same-origin, same-site ו-cross-origin. מומלץ לשלוח את הכותרת הזו לכל המשאבים כדי לציין אם הם מאפשרים טעינה על ידי אתרים אחרים.

דוגמה לשימוש

Cross-Origin-Resource-Policy: same-origin

איך משתמשים ב-CORP

שימושים מומלצים

מומלץ להציג את כל המשאבים עם אחת משלוש הכותרות הבאות.

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

Cross-Origin-Resource-Policy: same-origin

הגבלת משאבים לטעינה מתוך same-site

מומלץ להחיל את same-site על משאבים שדומים לאלה שמפורטים למעלה, אבל מיועדים לטעינה על ידי תת-דומיינים אחרים באתר.

Cross-Origin-Resource-Policy: same-site

הערה: מידע נוסף על ההבדל בין מקור זהה לבין אתר זהה זמין במאמר הסבר על 'אתר זהה' ו'מקור זהה'.

דפדפנים נתמכים

תמיכה בדפדפנים

• 73
• 79
• 74
• 12

מקור

מידע נוסף

• פריסה של מדיניות בנושא משאבים ממקורות שונים
• איך מבודדים את האתר מ-origin שונים באמצעות COOP ו-COEP
• למה צריך 'מבודד ממקורות שונים' כדי ליהנות מתכונות מתקדמות

מדיניות פותחן מרובות מקורות (COOP)

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

הכותרת Cross-Origin-Opener-Policy מאפשרת למסמך לבודד את עצמו מחלונות ממקורות שונים שנפתחו דרך window.open() או מקישור עם target="_blank" בלי rel="noopener". כתוצאה מכך, לכל גורם פותח של המסמך ממקורות שונים לא תהיה הפניה אליו ולא תהיה לו אפשרות לקיים איתו אינטראקציה.

שימוש לדוגמה

Cross-Origin-Opener-Policy: same-origin-allow-popups

איך משתמשים ב-COOP

שימושים מומלצים

אתם יכולים לבדוק איך ההגדרות הבאות משפיעות על התקשורת עם חלון קופץ ממקורות שונים בהדגמה הזו. משנים את התפריט הנפתח Cross-Origin-Opener-Policy גם במסמך וגם בחלון הקופץ, לוחצים על הלחצן Open a popup ואז על 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 הוא ערך ברירת המחדל, אבל אפשר לציין במפורש שאפשר לפתוח את המסמך הזה באמצעות חלון ממקורות שונים ולשמור על הגישה ההדדית.

כש-unsafe-none הוא ברירת המחדל, מפתחי האתרים צריכים לשלוח את same-origin או את same-origin-allow-popups באופן מפורש כדי להגן על האתר שלהם מפני התקפות בערוץ צדדי.

Cross-Origin-Opener-Policy: unsafe-none

הערה: תכונות כמו SharedArrayBuffer או performance.measureUserAgentSpecificMemory() מושבתות כברירת מחדל. בדפדפנים מסוימים אפשר להשתמש בהם בהקשרים 'מופרדים בין מקורות', שבהם צריך להגדיר את הכותרות COOP ו-COEP. מידע נוסף זמין במאמר איך מבודדים את האתר מקוד מקור זר באמצעות COOP ו-COEP.

דפוסי דיווח שלא תואמים ל-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"

דפדפנים נתמכים

תמיכה בדפדפן

• 83
• 83
• 79
• 15.2

מקור

מידע נוסף

• למה צריך 'מבודד ממקורות שונים' כדי ליהנות מתכונות מתקדמות

שיתוף משאבים בין מקורות (CORS)

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

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

דוגמה לשימוש

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

איך משתמשים ב-CORS

לפני שמתחילים להגדיר את 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.

שימושים מומלצים

בקשה פשוטה

כשבקשה עומדת בקריטריונים לבקשה פשוטה, הדפדפן שולח בקשת CORS עם כותרת 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 Sharing ואז על הלחצן 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 מאפשר למגיש הבקשה להגדיר את כותרות ה-HTTP X-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 שניות.

דפדפנים נתמכים

תמיכה בדפדפן

• 4
• 12
• 3.5
• 4

מקור

מידע נוסף

• שיתוף משאבים בין מקורות (CORS)
• שיתוף משאבים בין מקורות (CORS) – HTTP | MDN

מדיניות כלי להטמעה ממקורות שונים (COEP)

כדי לצמצם את היכולת של התקפות מבוססות-ספקטר לגנוב משאבים ממקורות שונים, תכונות כמו SharedArrayBuffer או performance.measureUserAgentSpecificMemory() מושבתות כברירת מחדל.

Cross-Origin-Embedder-Policy: require-corp מונע ממסמכים ומעובדים לטעון משאבים ממקורות שונים, כמו תמונות, סקריפטים, גיליונות סגנונות, iframe ועוד, אלא אם המשאבים האלה מאשרים באופן מפורש את הטעינה שלהם באמצעות כותרות CORS או CORP. אפשר לשלב את COEP עםCross-Origin-Opener-Policy כדי לצרף מסמך לבידוד בין מקורות.

משתמשים ב-Cross-Origin-Embedder-Policy: require-corp כדי להפעיל בידוד בין מקורות במסמך.

דוגמה לשימוש

Cross-Origin-Embedder-Policy: require-corp

איך משתמשים ב-COEP

דוגמאות לשימוש

הערך של COEP הוא require-corp. שליחת הכותרת הזו מאפשרת להורות לדפדפן לחסום את טעינת המשאבים שלא הביעו הסכמה באמצעות CORS או CORP.

אתם יכולים לבדוק איך ההגדרות הבאות משפיעות על טעינת המשאבים בדמו הזה. משנים את התפריט הנפתח Cross-Origin-Embedder-Policy, את התפריט הנפתח Cross-Origin-Resource-Policy, את התיבה Report Only וכו' כדי לראות איך הם משפיעים על טעינת המשאבים. בנוסף, פותחים את הדמו של נקודת הקצה לדיווח כדי לראות אם המשאבים החסומים מדווחים.

הפעלת בידוד בין מקורות

כדי להפעיל בידוד בין מקורות, שולחים את הערך 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"

דפדפנים נתמכים

תמיכה בדפדפן

• 83
• 83
• 79
• 15.2

מקור

מידע נוסף

• איך מבודדים את האתר מ-origin שונים באמצעות COOP ו-COEP
• למה צריך 'בידוד בין מקורות' כדי לקבל תכונות מתקדמות
• מדריך להפעלת בידוד ממקורות שונים

HTTP Strict Transport Security ‏(HSTS)

התקשורת בחיבור HTTP פשוט לא מוצפנת, ולכן הנתונים שמועברים יהיו נגישים לציתים ברמת הרשת.

הכותרת Strict-Transport-Security מעדכנת את הדפדפן שאסור לו לטעון את האתר באמצעות HTTP, אלא להשתמש ב-HTTPS במקום זאת. אחרי ההגדרה, הדפדפן ישתמש ב-HTTPS במקום ב-HTTP כדי לגשת לדומיין ללא הפניה אוטומטית למשך זמן שמוגדר בכותרת.

שימוש לדוגמה

Strict-Transport-Security: max-age=31536000

איך להשתמש במנגנון HSTS

שימושים מומלצים

כל האתרים שעוברים מ-HTTP ל-HTTPS צריכים להשיב עם כותרת Strict-Transport-Security כשמתקבלת בקשה עם HTTP.

Strict-Transport-Security: max-age=31536000

דפדפנים נתמכים

תמיכה בדפדפן

• 4
• 12
• 4
• 7

מקור

מידע נוסף

• Strict-Transport-Security - HTTP

קריאה נוספת

• פיתוח אתרים אחרי Spectre