[{"data":1,"prerenderedAt":165},["ShallowReactive",2],{"publication:he:P080":3},{"meta":4,"copy":16,"relatedArticles":135,"terms":157,"term":158,"resourceParent":159,"glossaryParent":162},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":9,"description":10,"incoming":11,"updated":14,"preparedOn":15},"P080","\u002Fblog\u002Fwebhook-security","article","איך מאבטחים webhook","איך מאבטחים webhook ומונעים טיפול כפול באירועים","אבטחת webhook באתר עסקי: אימות לפי הספק, חתימה, מסירות חוזרות, הרשאות וטיפול כפול. כולל טבלת בדיקות ותרחיש CRM להמחשה.",[12,13],"\u002Fservices\u002Fcrm-integrations","\u002Fservices\u002Fintegrations","2026-06-24","2026-10-29",{"intro":17,"sections":18,"checklist":95,"faq":101,"sources":111,"links":115,"cta":130},"כדי לאבטח webhook צריך לאמת את המסירה לפי מנגנון הספק, לבדוק שהאירוע שייך לחשבון ולפעולה המצופים, ולמנוע עיבוד עסקי כפול. HTTPS חשוב לתעבורה אך אינו מוכיח מי יזם כל בקשה. חיבור אמין מטפל גם בניסיונות חוזרים, בכשלים ובשמירת מידע מצומצמת, ולא רק באירוע ראשון שעבר בהצלחה.",[19,24,33,69,80,85],{"title":20,"paragraphs":21},"ממפים את כיוון החיבור לפני בחירת ההגנה",[22,23],"Webhook הוא הודעת אירוע שנשלחת לכתובת שהוגדרה מראש. בחנות, לדוגמה, מערכת חיצונית יכולה להודיע שהשתנה מצב הזמנה; בחיבור אחר האתר הוא השולח אל CRM. קבלת הודעה ושליחה לכתובת שהלקוח מזין הן שתי נקודות בדיקה שונות, ולכן לא מסיקים שאישור החיבור בכיוון אחד מכסה את שניהם.","רשמו מי השולח, מי המקבל, אילו אירועים נחוצים ואיזו פעולה עסקית כל אחד מפעיל. הפרידו סביבת ניסיון וחשבונות אמת. הודעה שהתקבלה אינה אישור גורף לבצע פעולה על כל לקוח או הזמנה. כשמקור הנתונים או מזהה החשבון אינם ברורים, עוצרים לפני שינוי מצב במערכת עסקית.",{"title":25,"paragraphs":26,"sources":29},"אימות מסירה צריך להתאים לתיעוד הספק",[27,28],"ב-GitHub, לדוגמה, אימות המסירה משתמש בסוד משותף ובחתימת HMAC על תוכן ההודעה. המקבל מחשב ומשווה את החתימה בדרך שהספק מגדיר לפני עיבוד. אין להעתיק שם כותרת או אלגוריתם מספק אחד לאחר. יש לשמור על תוכן הבקשה הנדרש לאימות ולהשתמש בספרייה או במימוש נתמך ובהשוואה המתאימה.","בפועל חשוב לזהות אם המנגנון חותם על גוף הבקשה הגולמי או על מבנה אחר. שינוי סדר שדות או עיבוד JSON לפני האימות עלולים לשנות את החומר שנבדק. אחרי אימות בוחנים גם מבנה ושדות צפויים, גודל בקשה והגבלת עומס, בהתאם למוצר. אלו בדיקות נפרדות מתעודת TLS תקינה.",[30],{"label":31,"url":32},"GitHub: אימות חתימות של מסירות webhook","https:\u002F\u002Fdocs.github.com\u002Fen\u002Fwebhooks\u002Fusing-webhooks\u002Fvalidating-webhook-deliveries",{"title":34,"paragraphs":35,"table":38,"sources":65},"בדקו חוזה, הרשאות וכפילויות בנפרד מהחתימה",[36,37],"גם אחרי אימות מקור צריך לוודא שסוג האירוע, החשבון והמזהה מתאימים לתהליך המורשה. חתימה תקינה אינה מבטיחה שהפעולה העסקית עדיין נחוצה. מסירה חוזרת יכולה להיות לגיטימית אחרי כשל, ולכן המערכת צריכה להבחין בין קבלת ההודעה לבין ביצוע הפעולה בפועל.","הטבלה היא רשימת קבלה מקורית לחיבור עסקי. משלימים אותה לפי חוזה המסירה של הספק, לרבות סדר אירועים וזמן תגובה. אישור קבלה לפני שהמידע נשמר באופן אמין עלול לאבד עבודה, ואישור רק אחרי עיבוד ארוך עלול לגרור ניסיונות חוזרים.",{"caption":39,"headers":40,"rows":44},"בדיקות לחיבור לפני מסירה",[41,42,43],"שכבה","מה מאמתים","תוצאה צפויה בניסוי מורשה",[45,49,53,57,61],[46,47,48],"זהות ושלמות","מנגנון האימות של הספק","מסירה שאינה מאומתת אינה מפעילה פעולה",[50,51,52],"תחום עסקי","חשבון, סוג אירוע ומזהה משאב","אירוע מחוץ להיקף אינו משנה נתונים",[54,55,56],"כפילויות","מזהה אירוע וכלל עיבוד עקבי","מסירה חוזרת אינה יוצרת רשומה נוספת",[58,59,60],"כשל זמני","שמירה, ניסיון חוזר ומעקב","הפעולה ניתנת לבירור בלי לנחש",[62,63,64],"מידע אישי","שדות ולוגים הנחוצים לתפעול","אין תיעוד מלא של סודות ותוכן לקוחות",[66],{"label":67,"url":68},"GitHub: אירועים, מסירות חוזרות ומזהי מסירה","https:\u002F\u002Fdocs.github.com\u002Fen\u002Fwebhooks\u002Fusing-webhooks\u002Fbest-practices-for-using-webhooks",{"title":70,"paragraphs":71,"sources":75},"מסירה חוזרת, replay וסדר אירועים",[72,73,74],"מזהה אירוע או מסירה יכול לסייע בזיהוי חזרה, אך אופן השימוש תלוי בספק. ב-GitHub מתועד מזהה מסירה שנשאר זהה בשליחה חוזרת של אותה מסירה. אצל ספק אחר ייתכן מודל אחר. אם יש חותמת זמן חתומה וכלל תוקף נתמך, בודקים אותם לפי התיעוד; אין להמציא חלון שרירותי שעלול לפסול הודעות תקינות.","מניעת כפילות צריכה להיות עקבית גם כששני עיבודים מתחילים כמעט יחד. בתכנון בוחנים תיעוד מצב, תור או מנגנון שמונע ביצוע חוזר של אותה פעולה. אם הודעות יכולות להגיע בסדר שונה, קובעים איך מבררים את המצב העדכני. חתימה לבדה אינה פותרת replay, סדר אירועים או התאוששות מכשל.","מזהה שמגיע בכותרת שאינה מכוסה בחתימה אינו הוכחה קריפטוגרפית לייחוד האירוע. אין להציג שמירת מזהים בלבד כהגנת replay מלאה. משלבים מידע מאומת וכללי מצב של הפעולה, ובודקים את המגבלות של פרוטוקול הספק לפני שמבטיחים מה החיבור מונע.",[76,77],{"label":67,"url":68},{"label":78,"url":79},"OWASP: אבטחת קבלת ושליחת webhooks","https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FWebhook_Security_Cheat_Sheet.html",{"title":81,"paragraphs":82},"דוגמה: אותה פנייה מגיעה ל-CRM פעמיים",[83,84],"בתרחיש להמחשה בלבד, טופס יוצר אירוע, המקבל שומר את הפנייה אך התשובה לשולח מתעכבת. הספק מנסה למסור שוב. בלי זיהוי עקבי נוצרים שני כרטיסים, ושני אנשי מכירות יכולים לפנות לאותו אדם. הבעיה אינה בהכרח תקיפה; היא יכולה לנבוע מתכנון חלקי של הטיפול החוזר.","בדיקת הקבלה משתמשת בנתוני ניסיון ובמנגנון בדיקה או מסירה חוזרת שהספק מאפשר. מצפים לפנייה עסקית אחת ולתיעוד מסירות שניתן לקשר אליה. לא משחזרים הודעת סליקה אמיתית ולא מפעילים חיוב כדי לבדוק כפילות. במקרה של אי התאמה משווים מזהים ופעולות לפני שמוחקים רשומות.",{"title":86,"paragraphs":87,"sources":90,"example":92},"כתובות יעד, לוגים ותנאי סיום",[88,89],"אם המערכת שולחת הודעות לכתובות שמשתמשים מגדירים, יש לבחון גם SSRF, הגבלת יעדים, הפניות ורשתות פנימיות. אישור HTTPS של יעד אינו מוכיח שמותר לשרת לפנות אליו. זו בדיקה נפרדת מהחתימה על ההודעה שמתקבלת אצלכם.","לצורכי תפעול שמרו מזהה מעקב, זמן, מצב ותיאור שגיאה מצומצם, בלי סוד חתימה ובלי גוף הודעה מלא כברירת מחדל. הגדירו מי בוחן מסירות שלא הושלמו ואיך מתאמים ניסיון חוזר. טיפול אינו סגור עד שיש ראיה למסירה תקינה, למצב כפול ולכשל שניתן לברר, בהיקף הבדיקה המוסכם.",[91],{"label":78,"url":79},{"title":93,"text":94},"תבנית מסירה לחיבור webhook","מקור ויעד: __. סביבה: __. אירוע מורשה: __. שיטת אימות לפי ספק: __. כלל כפילות: __. תרחיש כשל וניסיון חוזר: __. בדיקת סדר אירועים: __. מידע שנשמר ומי צופה בו: __. אחראי לטיפול בכשל: __.",[96,97,98,99,100],"מקור, יעד, חשבון וסביבה מתועדים.","האימות מתבצע לפני פעולה עסקית לפי תיעוד הספק.","נבדקו אירוע כפול, כשל זמני ומצב לא צפוי.","חתימה הופרדה מהרשאה ומכללי replay.","כתובות יעד ולוגים נכללו בבדיקה.",[102,105,108],{"question":103,"answer":104},"כתובת webhook ארוכה וסודית מספיקה?","אין להסתמך עליה כאימות יחיד. כתובות עלולות להופיע בתיעוד ולוגים. משתמשים במנגנון האימות שהספק תומך בו ומגנים גם על כתובת הקצה.",{"question":106,"answer":107},"חתימה תקינה מונעת עיבוד כפול?","לא, היא מסייעת לאימות המקור והשלמות בהתאם למנגנון. מניעת פעולה כפולה ובדיקת רלוונטיות האירוע הן בקרות נפרדות.",{"question":109,"answer":110},"אפשר לחסום כל מסירה שנייה של אירוע?","צריך לתכנן לפי מצב הפעולה וחוזה הספק. ייתכן שהמסירה הראשונה נכשלה לפני השלמה. המטרה היא פעולה עסקית נכונה אחת, עם אפשרות התאוששות ותיעוד.",[112,113,114],{"label":31,"url":32},{"label":67,"url":68},{"label":78,"url":79},[116,119,122,125,127],{"path":117,"label":118},"\u002Fblog\u002Fapi-keys-secrets","שמירת מפתחות וסודות של החיבור",{"path":120,"label":121},"\u002Fglossary\u002Fssrf","מה זה SSRF בשליחת בקשות מהשרת",{"path":123,"label":124},"\u002Fblog\u002Fshop-checkout-after-update","בדיקות מסירה לחנות לאחר שינוי",{"path":12,"label":126},"חיבור CRM ומערכות עסקיות",{"path":128,"label":129},"\u002Fservices\u002Fsecurity-audit","בדיקת תהליכים ונקודות קצה",{"title":131,"description":132,"button":133,"type":134},"החיבור עובד אבל לא ברור איך הוא מטפל בכשל?","נגדיר יחד היקף, מנגנון אימות ובדיקות קבלה למסירות חוזרות ונתונים, בהתאם לספק ולמערכות שלכם.","לתיאום בדיקה וטיפול","check",[136,143,150],{"id":137,"path":117,"title":138,"description":139,"category":140,"artwork":140,"order":141,"publishedOn":142},"P079","איפה שומרים מפתחות API באתר ואיך מחליפים סוד שנחשף","מדריך לניהול מפתחות API באתר עסקי: הפרדת צד שרת ודפדפן, הרשאות, סביבת בדיקה, החלפה ובירור חשיפה בלי לשלוח סודות לתמיכה.","integrations",93,"2026-07-10",{"id":144,"path":145,"title":146,"description":147,"category":140,"artwork":140,"order":148,"publishedOn":149},"P196","\u002Fblog\u002Fthird-party-script-data-flow","אילו נתונים רואים סקריפטים באתר ואיך בודקים גבולות","מפת גישה לסקריפטים חיצוניים: DOM, טפסים, Tag Manager ויעדי מידע. הבחנה בין data layer לבידוד, בדיקת טעינה ותעבורה וגבולות CSP ו-SRI.",77,"2026-06-08",{"id":151,"path":152,"title":153,"description":154,"category":140,"artwork":140,"order":155,"publishedOn":156},"P119","\u002Fblog\u002Fapi-security-business-checklist","רשימת בדיקה לאבטחת API עסקי: מה לבקש ומה לאמת","בדיקת אבטחת API לעסק: זהות, הרשאות לרשומה ולפעולה, מכסות, סודות, webhooks ורישום. שאלות לספק וטבלת קבלה עם משתמשי בדיקה ונתונים מלאכותיים.",69,"2026-05-23",[],null,{"path":160,"label":161},"\u002Fresources","כלים ורשימות בדיקה לאבטחת העסק: משאבים שימושיים",{"path":163,"label":164},"\u002Fglossary","מילון סייבר בעברית: מושגים עם הסברים מעשיים",1794134061815]