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

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

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas
Maud Nalpas
X GitHub

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

כותרות אבטחה מומלצות לאתרים שמטפלים בנתוני משתמשים רגישים:
Content Security Policy (CSP)
סוגים מהימנים
כותרות אבטחה מומלצות לכל האתרים:
X-Content-Type-Options
X-Frame-Options
מדיניות בנושא משאבים ממקורות שונים (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), הדלפות בין אתרים.

אינטרנט פוסט-ספקטר פיתוח אם הכותרות האלה מעניינות אותך.

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

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

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

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

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

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';
איך משתמשים ב-CSP

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, '&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;
איך להשתמש בסוגים מהימנים

  1. אכיפת סוגים מהימנים של sinks מסוכנים ב-DOM הכותרת של CSP ו'סוגים מהימנים': 

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

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

    כמובן שאפשר לשלב סוגים מהימנים עם הוראות 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>סוגים מהימנים</code> נוספים (לדוגמה, <code>trusted-types myPolicy</code>). עם זאת, זו לא דרישה.  &lt;/aside&gt;


    
  
  1. 
    
    הגדרת מדיניות
    
    
    מדיניות:
    
   
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}

    
    
  
    2. 
  
  2. 
    
    החלת המדיניות
    
    
    משתמשים במדיניות כשכותבים נתונים ב-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 מסוכן עם מחרוזת יוביל
      שגיאה.
    
  
    3. 



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



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


מידע נוסף

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 הנכונה.

X-Content-Type-Options: nosniff

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

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

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

תמיכה בדפדפן

  • Chrome: 64.
  • קצה: 12.
  • Firefox: 50.
  • Safari: 11.

מקור

מידע נוסף

X-Frame-Options

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

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

שימוש לדוגמה

X-Frame-Options: DENY
איך להשתמש ב-X-Frame-Options

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

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

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

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

X-Frame-Options: DENY 
X-Frame-Options: DENY

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

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

X-Frame-Options: SAMEORIGIN

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

תמיכה בדפדפן

  • Chrome: 4.
  • קצה: 12.
  • Firefox: 4.
  • Safari: 4.

מקור

מידע נוסף

מדיניות בנושא משאבים בין מקורות (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 ולוחצים על טעינה מחדש של 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 
Cross-Origin-Resource-Policy: same-origin

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

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

מדיניות משאבים בין מקורות: אותו אתר 
Cross-Origin-Resource-Policy: same-site

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

תמיכה בדפדפן

  • Chrome: 73.
  • קצה: 79.
  • Firefox: 74.
  • Safari: 12.

מקור

מידע נוסף

מדיניות בנושא פותחנים ממקורות שונים (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 
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 
Cross-Origin-Opener-Policy: same-origin-allow-popups

אפשר להפנות למסמך באמצעות חלונות ממקורות שונים

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

Cross-Origin-Opener-Policy: לא בטוח-ללא המשמעות של 
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"

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

תמיכה בדפדפן

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 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 בסביבה בנושא להדגמה. לוחצים על תיבת הסימון שיתוף משאבים בין מקורות ולוחצים על טעינת התמונה מחדש כדי לראות את האפקט.

בקשות קדם-הפעלה

לפני בקשת קדם-הפעלה מופיעה בקשת 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 מאפשר לבצע את הבקשה הבאה באמצעות ה-method 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 מציין אפשר לשלוח בקשות באמצעות ה-methods POST, GET ו-OPTIONS.
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type מציין את הערך הבא הבקשות יכולות לכלול את הכותרות X-PINGOTHER ו-Content-Type.
  • Access-Control-Max-Age: 86400 מציין שהתוצאה של קדם-ההפעלה אפשר לשמור את הבקשה במטמון למשך 86400 שניות.

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

תמיכה בדפדפן

  • Chrome: 4.
  • קצה: 12.
  • Firefox: 3.5.
  • Safari: 4.

מקור

מידע נוסף

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

איך COEP עובד

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

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

תמיכה בדפדפן

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

מקור

מידע נוסף

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

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

תמיכה בדפדפן

  • Chrome: 4.
  • קצה: 12.
  • Firefox: 4.
  • Safari: 7.

מקור

מידע נוסף

קריאה נוספת