דף זה תורגם על ידי Cloud Translation API.

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

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

אייג'י קיטמורה

ארתור יאנק

מוד נאלפ

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

כותרות אבטחה שמומלצות לאתרים שמטפלים בנתוני משתמשים רגישים:: מדיניות אבטחת תוכן (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';

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

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

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

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

* https: הוא חלופה ל-Safari, ו-unsafe-inline הוא חלופה לגרסאות ישנות מאוד של הדפדפן. המדיניות https: וגם unsafe-inline לא הופכות את המדיניות שלך לפחות בטוחה כי דפדפנים שתומכים ב-strict-dynamic יתעלמו מהן. מידע נוסף זמין במאמר הוספת חלופות לתמיכה ב-Safari ובדפדפנים ישנים יותר. * Safari אינו תומך עדיין ב-strict-dynamic. עם זאת, מדיניות CSP מחמירה, כמו בדוגמאות שלמעלה, בטוחה יותר מ-CSP ברשימת ההיתרים (ובטוחה הרבה יותר מ-CSP בכלל) לכל המשתמשים. גם ב-Safari, מדיניות CSP מחמירה מגינה על האתר מפני סוגים מסוימים של מתקפות XSS, מפני שנוכחות ה-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, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;

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

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

אכיפה של סוגים מהימנים עבור 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 &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;


<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, '>');
    }
  });
}

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


    
      שימושים מומלצים
מומלץ להשתמש ב-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>. מומלץ לשלוח את הכותרת הזו בכל המסמכים כדי לציין אם אפשר להטמיע אותם באמצעות מסמכים אחרים.

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

שימוש לדוגמה
X-Frame-Options: DENY


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


    
      שימושים מומלצים
בכל המסמכים שלא מיועדים להטמעה צריך להשתמש בכותרת X-Frame-Options.
בהדגמה הזו, תוכלו לנסות את ההשפעה של ההגדרות הבאות על טעינת iframe. משנים את התפריט הנפתח X-Frame-Options ולוחצים על הלחצן Reload the 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 בחלון דפדפן חדש. המדיניות בנושא משאבים בין מקורות מגינה על המשאב רק מפני הטמעה של אתרים אחרים.

Cross-Origin-Resource-Policy: same-origin

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

Cross-Origin-Resource-Policy: same-site

הערה:  מידע נוסף על ההבדל בין same-origin ל-same-site זמין במאמר הסבר על 'אותו אתר' ו'אותו מקור'. 
דפדפנים נתמכים

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        תמיכה בדפדפן
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  73
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  74
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
        
        
        מקור
        
      
    
    
    
  
מידע נוסף

  לשקול לפרוס את המדיניות לגבי משאבים ממקורות שונים
  הפיכת האתר ל'מבודד ממקורות שונים' באמצעות 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 לכן קופץ ואז על 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.
שימושים מומלצים
בקשה פשוטה
כשבקשה עומדת בקריטריונים של הבקשה הפשוטה, הדפדפן שולח בקשה ממקורות שונים עם כותרת 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 מאפשר למגיש הבקשה להגדיר את כותרות ה-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 מונע ממסמכים ומעובדים לטעון משאבים ממקורות שונים, כמו תמונות, סקריפטים, גיליונות סגנונות, iframes ואחרים, אלא אם המשאבים האלה בוחרים באופן מפורש להיטען באמצעות כותרות 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-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"

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        תמיכה בדפדפן
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  15.2
  
  
        
        
        מקור
        
      
    
    
    
  
מידע נוסף

  הפיכת האתר ל'מבודד ממקורות שונים' באמצעות 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

    
  


קריאה נוספת


פיתוח אינטרנט Post-Spectre