מפו קוד נטען ותנאים ולא רק שמות ספקים
רשמו מאין נטען כל סקריפט, באילו עמודים ומתי: כניסה, פעולה או תנאי נוסף. כללו קוד שמגיע דרך תוסף, כלי תגיות וצאט ולא רק תגיות שקיימות בתבנית. אותו ספק יכול להפעיל כמה רכיבים, ורכיב אחד יכול לטעון קוד נוסף. בדיקת עמוד הבית בלבד לא מכסה בהכרח טופס או קופה.
OWASP מתארת דרכי טעינה ישירות ועקיפות של JavaScript ואת הסיכון שבהרחבת גבול האמון. הרשימה צריכה לכלול מי מוסמך לפרסם שינוי ולמה הוא נחוץ. שינוי בכלי תגיות יכול להשפיע על מבקרים גם בלי פריסת קוד חדשה של האתר.
הקשר הרצה קובע יותר משם הקובץ
הטבלה היא מסגרת עבודה מקורית. היא אינה טוענת שכל ספק קורא כל שדה, אלא ממפה מה צריך לאמת. יכולת טכנית אפשרית, התנהגות שנצפתה והסכמה חוזית הן שלוש שאלות שונות; אף אחת אינה מחליפה את האחרות.
| שילוב | שאלת גישה | מה מאמתים |
|---|---|---|
| סקריפט בעמוד הראשי | אילו נתוני DOM זמינים בהקשר | קוד, תעבורה ותנאי הפעלה |
| Tag Manager | מי יכול להוסיף קוד ויעדים | הרשאות פרסום והיסטוריית שינוי |
| data layer | אילו ערכים נועדו להיאסף | שהוא אינו מוצג כבידוד קוד |
| iframe נפרד | איזו הפרדה ותקשורת הוגדרו | מקור, sandbox והודעות לפי הצורך |
| שילוב שרת | איזה מידע יוצא מהשרת | סכמה, יעדים והרשאות |
| קופה או טופס | מה משתנה בזמן הקלדה ושליחה | בדיקת ניסיון ללא מידע לקוחות |
data layer הוא ממשק נתונים ולא ארגז חול
אפשר להגדיר בו מידע מצומצם שהעסק רוצה להעביר למדידה, אך קוד שרץ בעמוד אינו בהכרח מוגבל לקריאתו בלבד. OWASP מדגישה ש-data layer אינו sandbox. צריך לבחון גם הרשאות כלי תגיות, קוד מותאם ואופן הטעינה ולא להסיק מבנה משתנים כמנגנון אכיפה.
גם שילוב שרת אינו הוכחה שאין קוד חיצוני בדפדפן. בודקים מה עדיין נטען בעמוד, ומה יוצא מכל רכיב. אם בוחרים הפרדה כגון iframe, יש לבדוק את התצורה ואת ערוץ התקשורת; שם הטכנולוגיה אינו אישור שכל מידע נחסם.
CSP ו-SRI עוזרים בשאלות שונות
CSP יכולה להגביל מקורות ואופני טעינה בהתאם למדיניות. SRI בודק התאמה של משאב לערך שלמות צפוי. אף אחד מהם אינו הוכחה שקוד שהותר אינו קורא מידע זמין בהקשר שלו. גם משאב שתוכנו תואם לערך שאושר יכול לבצע פעולה שלא מתאימה לצורך העסקי.
למשאב שמשתנה נדרש תהליך תחזוקת גרסה ובדיקת השפעה. אין להעתיק מדיניות שמפסיקה כל חיבור בלי לתכנן בדיקה, ואין להפוך חריגה גורפת לפתרון. בוחנים אכיפה ותפקוד בתנאים מתאימים, עם דרך חזרה למקרה ששינוי חוסם פעולה לגיטימית.
דוגמה: אירוע תודה כלל כתובת דואר בכתובת העמוד
התרחיש להמחשה בלבד. שדה מטופס הועבר ל-URL של עמוד תודה, וכלי מדידה אסף את הכתובת. בקשת העסק הייתה לספור פניות, לא להעביר פרטי קשר. הצוות מתקן את סכמת האירוע ובודק שוב טעינה ותעבורה עם ערכי ניסיון סינתטיים.
Google Analytics מזהירה ממידע מזהה בכתובות, בכותרות ובקלט שנשלח לשירות. זו דוגמה לדרישת מוצר, לא רשימה מלאה של כל חובות הפרטיות. היעדר מידע בפנייה אחת אינו שולל תנאי הפעלה אחר; מציינים אילו עמודים, פעולות ומצבים נבדקו.
סגרו בדיקה עם היקף, צורך ותוצאה שניתנת לחזרה
המסירה כוללת מקור קוד, בעלים, מידע נחוץ, יעדים והתנהגות שנצפתה בתנאים שנבדקו. לכל חריגה יש החלטה, אחראי וטריגר לבחינה לאחר שינוי ספק או קוד. אל תשלחו HAR מלא או צילום טופס עם מידע לקוח בערוץ פנייה רגיל; ראיות יכולות להכיל אסימונים ונתונים רגישים.
ב-CyberFixCrew אפשר לתאם סקירת אתר ותהליך מידע לפי השירותים הקיימים. הבדיקה אינה אישור שכל תנאי התנהגות של ספק נשלל. מסכמים מה נבדק, מה דורש גורם נוסף ואיך מאמתים צמצום בלי לפגוע בתהליך העסקי.
