התחילו ממפת האתר והתלויות, לא מרשימת ניקוד
רשמו את סוגי הדפים: תוכן ציבורי, טופס, אזור כניסה, ממשק ניהול ונתיב API אם יש. לכל סוג ציינו אילו שירותים חיצוניים נטענים ומה חייב לעבוד. דף בית סטטי, חנות עם ספק תשלום ומערכת לקוחות אינם מקבלים בהכרח אותה מדיניות. כותרת שנראית תקינה בדף הבית יכולה להיות שונה בדף אחר.
בדקו גם מי מוסיף את הכותרות: האפליקציה, שרת האחסון, CDN או שילוב שלהם. שינוי במקום אחד עשוי להישאר מוסתר מאחורי מטמון או להתנגש בכלל אחר. מגדירים נקודת אחריות ותיעוד מצב קיים לפני עדכון. בעל העסק יכול לאסוף את התלות והפעולות החשובות; שינוי מדיניות נעשה בידי מי שמכיר את סביבת הפריסה.
איזו כותרת מטפלת באיזו שאלה
כותרות HTTP הן הוראות שהשרת מחזיר, והמשמעות שלהן תלויה בסוג התגובה ובתמיכת הדפדפן. הטבלה מציגה שימושים עיקריים ואינה תצורת שרת מוכנה. OWASP מפרט התאמת סוג תוכן, צמצום ניחוש סוג קובץ ושליטה במידע הפניה; לכל בחירה צריך לצרף בדיקת תפקוד.
| כותרת או מנגנון | שאלת האבטחה | מה לבדוק באתר |
|---|---|---|
| Content-Security-Policy | אילו מקורות ופעולות מותרים למסמך | טפסים, סקריפטים ושירותי צד שלישי |
| Strict-Transport-Security | מתי הדפדפן דורש HTTPS | תעודות, תתי דומיינים ותחזוקה |
| X-Content-Type-Options | כיצד מטופל סוג התוכן המוצהר | סוג תוכן נכון גם במשאבים |
| Referrer-Policy | כמה מידע הפניה נשלח | קישורים פנימיים וחיצוניים רלוונטיים |
| frame-ancestors ב-CSP | מי רשאי להטמיע את הדף במסגרת | הטמעות עסקיות שצריכות להישאר תקינות |
CSP דורשת התאמה, בדיקה והחלטה על אכיפה
CSP יכולה להגביל משאבים ופעולות במסמך, אך המדיניות חייבת להתאים ליישום. לפני אכיפה ממפים תלויות ובוחנים את ההפרות בסביבה מתאימה. מצב Report-Only מאפשר לבחון מדיניות בלי לאכוף אותה; עצם קיומו אינו אומר שהמשאבים המפרים נחסמים. קבלת דוחות גם אינה הוכחה שכל תהליך באתר נבדק.
לדוגמה, צריך לברר אילו סקריפטים, מסגרות, יעדי טפסים וחיבורי דפדפן נחוצים, ולא לאשר כל מקור תחת כלל רחב אחד. רשימת מקורות לבדה אינה מספיקה לכל יישום. אם נדרש שינוי בדרך יצירת הסקריפטים או בדפים דינמיים, מתאמים אותו עם האחראי לקוד לפני מעבר לאכיפה. ערך CSP במילון מסביר את המנגנון; כאן המטרה היא תוכנית שינוי שניתן לבדוק.
מה דורש זהירות מיוחדת לפני שינוי
HSTS יכול להשפיע על כניסות עתידיות של דפדפנים שנחשפו למדיניות, ולכן בודקים מוכנות HTTPS והיקף תתי הדומיינים לפני הרחבה או התחייבות ממושכת. מדריך HSTS הנפרד מסביר את ההחלטה. אין להפעיל אפשרות רחבה רק כדי להשלים שורה בדוח, בלי להבין מי מנהל את כל השמות שבהיקף.
כותרת שמגבילה הטמעה עלולה לשנות עבודה של מערכת שמציגה את האתר במסגרת, ו-CSP יכולה להפריע לחיבור שלא מופה. גם הגדרה שנחשבת מחמירה אינה מוצלחת אם היא גורמת לצוות לעקוף אותה באופן קבוע. כשאין רשימת תלות או דרך חזרה, עוצרים לתכנון ולניסוי ולא עורכים כמה שכבות בו זמנית.
דוגמה: עמוד תוכן עובד וטופס הפנייה מפסיק להישלח
בתרחיש להמחשה בלבד, בדיקת דף הבית נראית תקינה אחרי החמרת מדיניות, אך טופס משתמש ביעד שלא נכלל במיפוי. המבקר רואה את העמוד, ובכל זאת הפעולה העסקית נכשלת. בדיקת כותרת בודדת אינה מגלה בהכרח את החוויה הזאת. לכן כוללים מסלול מילוי תקין, שגיאת קלט ומצב הצלחה במבחן הקבלה.
אם מתגלה חסימה, מזהים את ההוראה והיעד, בודקים שהוא נחוץ ומורשה, ומתקנים את המדיניות בהיקף הנדרש. לא פותחים את כל המקורות כדי להשתיק את ההודעה. משתמשים בנתוני ניסיון ובמניעת שליחות אמת לא מתואמות, ושומרים תיעוד של המצב לפני ואחרי השינוי.
בדיקת סיום היא גם אבטחה וגם עבודה תקינה
בדקו את התגובה הסופית לדפים מייצגים, כולל הבדלים בין נתיב ישיר, הפניה ומצב שגיאה רלוונטי. ודאו ששכבות הפריסה מחזירות את המדיניות שהתכוונתם אליה, שאין כללים לא צפויים ושנבדק גם דפדפן. בדיקת קוד מקומי לבדה אינה מוכיחה מה מוגש בשרת החי.
סוגרים את השינוי עם רשימת התהליכים שנבדקו, חריגות ידועות, אחראי ומועד בדיקה מחדש. בדוח מפרידים בין מדיניות במצב דיווח למדיניות נאכפת. כותרות אינן מחליפות תיקון חולשות, ניהול הרשאות או טיפול בסוד שנחשף; שיפורן הוא חלק מתוכנית אבטחת האתר.
