בעמוד הזה
- למה אפליקציה ש-Claude בנה צריכה בדיקת אבטחה?
- מה בדיוק הפקודה /security-review בודקת?
- איך עושים בדיקת אבטחה, צעד אחרי צעד?
- 1פותחים את Claude Code בתיקיית הפרויקט
- 2מריצים /security-review על השינויים האחרונים
- 3מבקשים בדיקה של כל הפרויקט
- 4בודקים את הספריות עם npm audit
- 5מתקנים לפי הסדר — ממצא אחד בכל פעם
- איך קוראים את התוצאות — ומה מתקנים קודם?
- איך בודקים נגישות בסיסית?
- האם מדיניות הפרטיות שלכם תואמת את מה שהאתר באמת אוסף?
- צ'קליסט לפני השקה — של אן
- אפשר להפוך את בדיקת האבטחה לאוטומטית?
- שאלות ותשובות
לפני שאתם מעלים לאוויר משהו ש-Claude Code בנה לכם, תריצו שתי בדיקות: את הפקודה המובנית `/security-review`, שבודקת את השינויים בענף (branch) הנוכחי, ופרומפט לבדיקת אבטחה של כל הפרויקט, שמבקש מ-Claude לעבור על כל קובץ. אחר כך עוד שלוש תוספות קצרות — npm audit לספריות, בדיקת נגישות, ובדיקה שמדיניות הפרטיות באמת מתארת את מה שהאתר אוסף. Claude בנה מהר. אבל אף אחד עוד לא בדק, וברגע שאנשים אמיתיים מכניסים שם שמות, טלפונים ותשלומים — האחריות היא עליכם, לא על Claude.
למה אפליקציה ש-Claude בנה צריכה בדיקת אבטחה?
כי "זה עובד" ו"זה בטוח" הן שתי שאלות שונות. כשאתם מבקשים מ-Claude טופס הזמנות, הוא בונה טופס הזמנות שעובד. הוא לא עוצר מעצמו לשאול: האם זר יכול לראות הזמנות של לקוחות אחרים? האם הסיסמה של מסד הנתונים כתובה בתוך הקוד? האם אפשר להקליד סקריפט בשדה "שם"? אלה השאלות שמפתח היה שואל לפני השקה — ואם אתם עושים vibe coding, אין מפתח בחדר. אז מבקשים מ-Claude לחבוש כובע אחר: כובע של בודק אבטחה.
Anthropic כותבים את זה במפורש בתיעוד האבטחה של Claude Code: האחריות לבדוק את הקוד והפקודות שמוצעים לפני שמאשרים היא שלכם. Claude בונה מצוין ובודק מצוין — אבל רק כשמבקשים ממנו לבדוק.
מה בדיוק הפקודה /security-review בודקת?
/security-review היא פקודה שמגיעה מובנית ב-Claude Code. לפי רשימת הפקודות בתיעוד, היא מנתחת את השינויים בענף הנוכחי שלכם ומחפשת פרצות אבטחה — היא בודקת את ההבדל בין הענף שלכם לענף הראשי ב-GitHub ("origin"), ומחפשת סיכונים כמו הזרקת קוד (injection), בעיות התחברות והרשאות, וחשיפת מידע.
בריפו הפתוח של Anthropic ל-GitHub Action המקביל מפורטים סוגי הבעיות שהניתוח הזה מחפש, ביניהם:
- הזרקות (Injection) — למשל SQL injection, כשמישהו מכניס פקודות למסד הנתונים דרך שדה בטופס.
- התחברות והרשאות — התחברות שבורה, משתמשים שמגיעים למקומות שהם לא אמורים להגיע אליהם.
- חשיפת מידע — סיסמאות או מפתחות שכתובים בתוך הקוד, מידע רגיש שנשמר בלוגים.
- XSS — מישהו שותל סקריפט בדף שלכם שרץ אצל גולשים אחרים.
- הגדרות — ברירות מחדל לא בטוחות, כותרות אבטחה (security headers) חסרות.
- שרשרת אספקה — ספריות (dependencies) עם פרצות מוכרות שהאפליקציה שלכם נשענת עליהן.
איך עושים בדיקת אבטחה, צעד אחרי צעד?
פותחים את Claude Code בתיקיית הפרויקט
פותחים טרמינל בתיקייה של האפליקציה שרוצים לבדוק ומפעילים את Claude Code. חדשים בזה? תתחילו ממה זה Claude Code (באנגלית).
מריצים /security-review על השינויים האחרונים
/security-review
ההרגל הכי טוב: להריץ אותה בכל פעם ש-Claude מסיים פיצ'ר חדש בענף, לפני שממזגים. אם מקבלים שגיאה שקשורה ל-origin, הפרויקט עוד לא מחובר ל-GitHub — פשוט ממשיכים לשלב 3.
מבקשים בדיקה של כל הפרויקט
זו הבדיקה החשובה לפני השקה ראשונה. תעתיקו בדיוק:
תעשה בדיקת אבטחה מלאה של כל הפרויקט, לא רק של השינויים האחרונים. תעבור על כל קובץ ותחפש: התחברות והרשאות; גישה למידע של משתמשים אחרים; SQL injection ו-XSS; העלאת קבצים; מפתחות API וסיסמאות שכתובים בתוך הקוד; ספריות עם פרצות מוכרות. תציג את הממצאים לפי חומרה, תסביר כל אחד בשפה פשוטה, ואל תשנה שום דבר עד שאאשר.
המשפט האחרון הוא הכי חשוב. אתם רוצים קודם דוח — לא שכתוב מפתיע של האפליקציה בלילה שלפני ההשקה.
בודקים את הספריות עם npm audit
אם בפרויקט יש קובץ package.json (ברוב האתרים והאפליקציות ב-JavaScript יש), מריצים:
npm audit
הפקודה שולחת תיאור של הספריות בפרויקט למאגר של npm ומקבלת דוח על פרצות מוכרות. npm audit fix מתקן את מה שאפשר לעדכן בבטחה. את npm audit fix --force עדיף לא להריץ אם אתם לא בטוחים — התיעוד של npm עצמו מזהיר שהיא יכולה להתקין עדכונים גדולים מחוץ לגרסאות שהגדרתם, וזה יכול לשבור את האפליקציה. לא בטוחים? תשאלו את Claude: "תסביר לי את הדוח של npm audit בשפה פשוטה ותגיד מה בטוח לתקן".
מתקנים לפי הסדר — ממצא אחד בכל פעם
מאשרים תיקון אחד בכל פעם, בודקים שהאפליקציה עדיין עובדת, ובסוף מריצים את הבדיקה שוב. הסדר — בסעיף הבא.
איך קוראים את התוצאות — ומה מתקנים קודם?
תקבלו רשימת ממצאים, בדרך כלל מסומנים בחומרה גבוהה, בינונית או נמוכה. לא להיבהל ולא לנסות לתקן הכול בבת אחת. זה הסדר שלי:
- 1. סודות בתוך הקוד. מפתח API, סיסמה למסד נתונים או מפתח של Stripe שכתובים בתוך קובץ. מחליפים אותו מיד — יוצרים מפתח חדש בלוח הבקרה של השירות ומבטלים את הישן — ורק אחר כך מעבירים למשתנה סביבה (environment variable). למחוק מהקוד זה לא מספיק: אם הקוד עלה פעם ל-GitHub, תניחו שהמפתח הישן כבר בחוץ.
- 2. חשיפת מידע של אנשים אחרים. כל דבר שמאפשר למשתמש אחד לראות, לשנות או למחוק רשומות של משתמש אחר — הזמנות, לידים, חשבוניות. מתקנים לפני השקה, בלי יוצא מן הכלל.
- 3. הזרקות ו-XSS. טפסים ושדות שמקבלים קלט מסוכן.
- 4. כל השאר. כותרות אבטחה חסרות, ספריות ישנות, חיזוקים "נחמדים שיהיו". מתכננים אותם, אבל בדרך כלל הם לא עוצרים השקה.
| ממצא | מה זה אומר במילים פשוטות | מה עושים |
|---|---|---|
| Hardcoded secret / מפתח API בקוד | סיסמה לאחד השירותים שלכם יושבת בתוך הקוד | מחליפים את המפתח עכשיו ומעבירים למשתנה סביבה |
| Broken access control / IDOR | משנים מספר בכתובת ורואים רשומה של מישהו אחר | מבקשים מ-Claude לבדוק בעלות על המידע בכל דף ובכל API |
| SQL injection | טקסט שמוקלד בטופס יכול להריץ פקודות על מסד הנתונים | מבקשים מ-Claude להשתמש בשאילתות עם פרמטרים בכל מקום |
| XSS | אפשר לשתול סקריפט שירוץ אצל הגולשים שלכם | מבקשים מ-Claude לנקות (sanitize) כל קלט של משתמשים |
| העלאת קבצים לא בטוחה | אפשר להעלות כל סוג קובץ, בכל גודל, לכל מקום | מגבילים סוגים וגודל, ושומרים מחוץ לתיקייה הציבורית |
| ספרייה עם פרצה מוכרת | לספרייה שאתם משתמשים בה יש חור ידוע ומפורסם | npm audit fix, ואז בודקים שהאפליקציה עובדת |
| Security headers חסרים | הדפדפן לא מקבל הוראה להפעיל הגנות נוספות | בדרך כלל עדיפות נמוכה — מוסיפים אחרי התיקונים הדחופים |
לא ברור מה ממצא אומר? מדביקים אותו בחזרה ל-Claude ושואלים: "תסביר לי את זה כאילו אני לא מפתחת. כמה זה חמור, ומה התיקון הבטוח הכי קטן?"
איך בודקים נגישות בסיסית?
נגישות פירושה שאנשים שמשתמשים בקורא מסך, במקלדת בלבד או בטקסט מוגדל יכולים באמת להשתמש באתר. התקן הבינלאומי הוא WCAG של ארגון W3C, והגרסה העדכנית היא WCAG 2.2. מבקשים מ-Claude לבדוק מולו:
תבדוק את האתר מול הבסיס של WCAG 2.2 ברמה AA: טקסט חלופי (alt) לתמונות, ניגודיות צבעים של טקסט, ניווט מלא במקלדת (כולל תפריטים וטפסים), סימון פוקוס נראה לעין, תווית לכל שדה בטופס, והודעות שגיאה ברורות. תפרט מה חסר, דף אחרי דף, בשפה פשוטה. אל תשנה כלום בינתיים.
האם מדיניות הפרטיות שלכם תואמת את מה שהאתר באמת אוסף?
את זה כמעט כולם מדלגים. Claude מייצר הרבה פעמים דף מדיניות פרטיות מתבנית — ואז אתם מוסיפים טופס יצירת קשר, Google Analytics, פיקסל של פייסבוק ו-Stripe, והמדיניות לא מזכירה אף אחד מהם. Claude יכול לקרוא גם את הקוד וגם את המדיניות, אז תנו לו להשוות:
תפרט את כל מה שהאתר הזה באמת אוסף או משתף: כל שדה בכל טופס, עוגיות (cookies), סקריפטים של אנליטיקס ומעקב, ספקי תשלום, כלי מייל, וכל שירות חיצוני שמקבל מידע על משתמשים. אחר כך תשווה את הרשימה לדף מדיניות הפרטיות שלנו ותראה לי מה חסר במדיניות או כתוב בה לא נכון. אל תשכתב את המדיניות — רק תן לי את הפערים.
יש חוקי פרטיות בישראל, בארה״ב ובאירופה, והם שונים זה מזה. Claude יכול להראות לכם את הפערים — הוא לא יכול להגיד לכם מה החוק דורש מהעסק שלכם. לאישור משפטי, קחו את הרשימה הזו לעורך/ת דין. תחסכו להם (ולעצמכם) הרבה זמן.
צ'קליסט לפני השקה — של אן
- `/security-review` אחרי כל פיצ'ר חדש, לפני מיזוג.
- הפרומפט לבדיקת כל הפרויקט פעם אחת לפני ההשקה הראשונה, ושוב אחרי שינויים גדולים.
- `npm audit` — ובלי
--forceאם אני לא מבינה למה. - אין סודות בקוד. כל מפתח במשתני סביבה; כל מפתח שהיה פעם בקוד — מוחלף.
- שני חשבונות בדיקה. אני נכנסת כמשתמש א' ומנסה לפתוח רשומות של משתמש ב'. אם הצלחתי — זה עוד לא מוכן.
- בדיקת נגישות מול WCAG 2.2 AA — ואני עוברת בעצמי על הטופס הראשי עם מקש Tab.
- פערים במדיניות הפרטיות — Claude מפרט, עורך/ת דין מאשר/ת.
- כותבת את הכללים ב-CLAUDE.md — "אף פעם לא לשים מפתחות בקוד, תמיד לבדוק למי שייך המידע" — כדי ש-Claude יזכור בפעם הבאה. ראו איך לכתוב CLAUDE.md טוב (באנגלית).
אפשר להפוך את בדיקת האבטחה לאוטומטית?
כן, אם הפרויקט שלכם נמצא ב-GitHub. Anthropic מפרסמים GitHub Action בקוד פתוח, anthropics/claude-code-security-review, שמריץ ניתוח מאותו סוג על כל pull request ומשאיר הערות על השורות שמדאיגות אותו. הוא מנתח רק את הקבצים שהשתנו ב-pull request, וב-README שלו כתוב שהוא לא מחוסן מפני prompt injection — אז מפעילים אותו רק על pull requests שאתם סומכים עליהם. לרוב מי שבונה לבד, להריץ ידנית את /security-review ואת הפרומפט לבדיקת כל הפרויקט זה יותר ממספיק.
רוצים לבנות — ולהשיק — בביטחון?
בקורס הזום שלי בעברית בונים דברים אמיתיים עם Claude Code, צעד אחרי צעד, כולל איך לבדוק אותם לפני שהם עולים לאוויר.
שאלות ותשובות
מה עושה הפקודה /security-review ב-Claude Code?
זו פקודה מובנית ב-Claude Code שמנתחת את השינויים בענף הנוכחי ומחפשת פרצות אבטחה. היא בודקת את ההבדל בין הענף שלכם לענף הראשי ב-origin, ומחפשת סיכונים כמו הזרקות (injection), בעיות התחברות והרשאות, וחשיפת מידע. היא צריכה שלפרויקט יהיה remote בשם origin (למשל ריפו ב-GitHub).
האם /security-review בודקת את כל הפרויקט?
לא. היא מתמקדת בשינויים שעוד לא מוזגו בענף הנוכחי. כדי לבדוק אפליקציה שלמה — במיוחד כזו ש-Claude בנה מאפס — מבקשים מ-Claude בדיקה של כל הפרויקט במילים פשוטות: לעבור על כל קובץ, לפרט ממצאים לפי חומרה, ולא לשנות כלום עד שאתם מאשרים.
מצאתי מפתח API בתוך הקוד. מה עושים?
מחליפים אותו מיד: יוצרים מפתח חדש בלוח הבקרה של השירות ומבטלים את הישן. אחר כך שומרים את המפתח החדש במשתנה סביבה ולא בקוד. למחוק אותו מהקובץ זה לא מספיק, כי המפתח הישן יכול כבר להיות בהיסטוריה של Git או ב-GitHub.
האם npm audit מספיק כדי לאבטח את האפליקציה?
לא. npm audit מדווח רק על פרצות מוכרות בספריות שהפרויקט משתמש בהן. הוא לא בודק את הקוד שלכם — למשל מי יכול לראות איזה מידע, או איך טפסים מטפלים בקלט. משתמשים בו יחד עם /security-review ועם בדיקה של כל הפרויקט.
האם Claude יכול להפוך את האתר שלי לנגיש או תואם לחוקי פרטיות?
Claude יכול לבדוק את האתר מול הבסיס של WCAG 2.2 ברמה AA, ולהשוות בין מה שהאתר אוסף לבין מה שכתוב במדיניות הפרטיות. זה שלב ראשון שימושי מאוד, אבל זה לא ייעוץ משפטי ולא הסמכה. לאישור משפטי פונים לעורך/ת דין, ובמקרה הצורך גם ליועץ/ת נגישות.
לתת ל-Claude לתקן את ממצאי האבטחה לבד?
קודם מבקשים דוח, ואז מאשרים תיקונים אחד אחד — מתחילים בסודות בתוך הקוד ובכל מה שחושף מידע של משתמשים אחרים. בודקים את האפליקציה אחרי כל תיקון, ובסוף מריצים את הבדיקה שוב.
לקרוא זה הצעד הראשון. לעשות — זה המועדון.
סקילים ומדריכים חדשים ראשונים, קורסים ברגע שהם יוצאים, וקהילה שעונה כשנתקעים. $69 לחודש.
נכתב על ידי Ann Alalouf. ראיתם משהו שכבר לא מעודכן? ספרו לנו — אנחנו שומרים על המדריכים עדכניים. פורסם ב-29 באוק׳ 2026.
