Vibe to Devhttps://www.vibetodev.com/he · משאב חינמי לקהילה
צ'קליסט השקה: 30 בדיקות לפני שעולים לאוויר
רשימת בדיקות לפני העלייה לאוויר של אתרים ואפליקציות שנבנו בעזרת AI. כל סעיף מגן עליכם מכשל כמו מפתח API שדלף, משתמש שרואה נתונים של משתמש אחר, מסד נתונים שאבד, חשבון מפתיע או מדיניות פרטיות חסרה. מסמנים מה שכבר נעשה. ובסעיף שאתם לא בטוחים בו, מעתיקים את ההנחיה: סוכן הפיתוח שלכם (Claude Code, Cursor או Copilot) בודק ומראה לכם את הראיות, ואתם מחליטים אם זה עבר. בדיקות האבטחה פתוחות לכולם, והשאר זמינות אחרי כניסה חינמית לחשבון.
אבטחה0/8
מפתחות שדלפו, בדיקות הרשאה חסרות ומסדי נתונים פתוחים. רוב הבדיקות לוקחות כמה דקות.
מידע סודי נשמר במנהל סודות (secret store), לעולם לא בקוד
שמרו את .env ב־.gitignore והעבירו לסביבת הייצור את המפתחות דרך הגדרות הסביבה של האירוח. חפשו במאגר וב־JavaScript שנבנה את sk_, key=, secret ואת מפתח service_role של Supabase. מחיקת השורה לא עוזרת, כי Git שומר כל גרסה: אם מפתח נכנס אי פעם ל־commit, החליפו אותו.
חפשו במאגר הזה, בכל היסטוריית git ובחבילת ה־JavaScript של סביבת הייצור מפתחות API, טוקנים וסיסמאות. רשמו כל ממצא עם הקובץ וה־commit. אל תשנו דבר; אמרו לי אילו מפתחות עליי להחליף אצל הספק.
כל הרשאה נבדקת בשרת
הסתרת כפתור היא לא הרשאה. היכנסו כמשתמש A, העתיקו כתובת או בקשת API ששייכת למשתמש B ונסו אותה. אתם אמורים לקבל 403 או 404, אף פעם לא את הנתונים של B.
רשמו כל נתיב API ופעולת שרת באפליקציה. לכל אחד הראו את השורה המדויקת שבודקת שמותר למשתמש המחובר לגשת לרשומה. סמנו כל נתיב שסומך על id מהדפדפן בלי לבדוק בעלות.
כללי מסד הנתונים פעילים (Supabase RLS, Firebase rules)
אם הדפדפן מדבר ישירות עם מסד הנתונים, המפתח הציבורי מגיע לכל אחד והכללים הם המנעול היחיד. לכל טבלה צריכה להיות אבטחה ברמת שורה (row-level security) עם מדיניות לכל פעולה.
רשמו את כל טבלאות מסד הנתונים, האם אבטחה ברמת שורה פעילה, ותארו כל מדיניות במילים פשוטות. אחר כך תנו לי בקשת בדיקה שאוכל להריץ כמשתמש בדיקה רגיל ומחובר כדי לוודא שאי אפשר לקרוא שורות של משתמש אחר.
HTTPS בכל מקום וכתובת ראשית אחת
מי שמקליד http:// או את הכתובת בלי www נוחת על אותה כתובת https://, עם המנעול.
בדקו את האתר החי שלי: האם http:// מפנה ל־https://, האם www והדומיין ללא www מגיעים לאותה כתובת, ומתי תעודת ה־TLS פגה? הציגו את כותרות התגובה האמיתיות כראיה.
טופסי הרשמה, כניסה ויצירת קשר מוגנים מבוטים
הגבילו בקשות לפי IP, הוסיפו CAPTCHA בטפסים ציבוריים (Cloudflare Turnstile חינמי), ואמתו כתובות אימייל לפני שחשבון יכול לבצע פעולה יקרה.
מצאו כל טופס ציבורי וכל נקודת קצה ששולחת אימייל, קוראת ל־API בתשלום או יוצרת חשבון. לכל אחד אמרו לי מה מונע מסקריפט לקרוא לו 10,000 פעמים, והציעו את ההגבלה או ה־CAPTCHA הכי קטנים שאפשר להוסיף.
כל קלט משתמש נבדק ומועבר כפרמטרים
טפסים, פרמטרים בכתובת, גופי JSON והעלאות קבצים. שאילתות עם פרמטרים, פלט שעובר escaping, והעלאות שמוגבלות לפי סוג וגודל. בדיקת קלט בדפדפן היא נוחות, לא הגנה.
לכל נתיב API ופעולת שרת, רשמו את השדות שנקראים מהבקשה והציגו את השורה שבה כל אחד נבדק בשרת. סמנו SQL גולמי שנבנה ממחרוזות, HTML שמוצג מתוך קלט משתמש וכל העלאה ללא בדיקת סוג וגודל.
גרסאות התלויות עדכניות ונבדקו, וכותרות האבטחה מוגדרות
npm audit לא מציג בעיות קריטיות והגרסאות מקובעות. האתר החי שולח את כותרות האבטחה (Content-Security-Policy, X-Content-Type-Options, X-Frame-Options ו־HSTS): ביחד הן מגבילות אילו סקריפטים רצים, מונעות מאתרים אחרים להציג את האתר שלכם בתוך מסגרת ומכריחות HTTPS. CORS מאפשר רק את הדומיינים שלכם, ובסביבת הייצור לא נשלחות source maps.
הריצו בדיקת אבטחה לתלויות של הפרויקט ורשמו ממצאים בדרגת critical ו־high עם התיקון. אחר כך משכו את דף הבית החי שלי ודווחו אילו כותרות אבטחה חסרות, מה CORS מאפשר והאם source maps מוגשות בסביבת הייצור.
חשבונות הניהול שלכם משתמשים באימות דו־שלבי
GitHub, ספק האירוח, מסד הנתונים, רשם הדומיין, ספק התשלומים והאימייל. מי שנכנס לאחד מהם משתלט על האפליקציה.
תנו לי רשימה של כל חשבון שהאפליקציה תלויה בו (אירוח, מסד נתונים, דומיין, DNS, תשלומים, אימייל וספקי AI), עם דף ההגדרות שבו מפעילים אימות דו־שלבי לכל אחד.
נתונים וגיבויים0/2
קוד אפשר לפרוס מחדש בדקה. נתונים שנמחקו לא חוזרים.
- יש גיבויים, ושחזרתם אחד מהם
- לעולם אל תבדקו מול מסד הנתונים של סביבת הייצור
ניטור0/4
ההבדל בין חמש דקות קשות לסוף שבוע קשה.
- השגיאות מגיעות אליכם, מקובצות ועם פירוט מחסנית הקריאות
- שירות חיצוני בודק את האתר כל כמה דקות
- אתם יודעים לחזור לגרסה קודמת, וכבר ניסיתם
- אתם יכולים למצוא יומנים של בקשה שנכשלה
חיובים וחידושים0/3
תקלות שקטות שממתינות חודשים ואז פוגעות בבת אחת.
- לכל שירות שמחייב לפי שימוש יש מגבלת הוצאה
- התשלומים משתמשים במפתחות חיים, וחתימת ה־webhook נבדקת
- חידוש הדומיין האוטומטי פעיל והכרטיס הרשום תקף
משפט ואמון0/9
זול לטפל בזה עכשיו, יקר אחרי תלונה.
- מדיניות הפרטיות תואמת למה שהאפליקציה באמת אוספת
- טפסים מבקשים רק את הדרוש
- עוגיות וכלי מעקב ממתינים להסכמה
- מדיניות עוגיות שמפרטת את העוגיות האמיתיות
- תנאי שימוש ופרטי עסק אמיתיים מפורסמים
- ההסכמה אינה מסומנת מראש, ולשיווק יש תיבת סימון משלו
- אם אתם מוכרים: מדיניות החזרים, החזרות ומשלוחים
- אין ביקורות, המלצות או מספרים מומצאים, ויש זכויות לכל תמונה
- בדיקות הנגישות הבסיסיות עוברות
בדיקות בתנאים אמיתיים0/4
לא בדפדפן שלכם ועם החשבון שלכם. בטלפון של מישהו אחר.
- האפליקציה עובדת בטלפון אמיתי
- אימיילים מגיעים לתיבת הדואר הנכנס ולא לספאם
- עמודי 404 ושגיאה מועילים
- לאתר יש כותרת, תיאור ותצוגה מקדימה לקישור
🌙 כל סעיף כאן נלמד בקורס Production, והקורס ממשיך גם אחרי יום ההשקה.
- 64 נושאים, ולא רק 30 שורות. כל אחד מוסבר במילים פשוטות: מה נשבר, איך בודקים, ודוגמה שעובדת.
- 8 תרגילים באפליקציה שלכם.ה־AI מוסיף התראות על שגיאות, רובוט שעובר על המסלול המרכזי באפליקציה, rollback שתורגל, גיבוי ששוחזר בפועל, כללי גישה למסד הנתונים ותקרות הוצאה, ומראה לכם הוכחה לכל אחד מהם.
- מה להגיד ל־AI בשלוש לפנות בוקר.כל נושא מסתיים בהנחיה מדויקת לרגע שמשהו נשבר. הנה אחת מהן:
הגרסה האחרונה שלי שברה משהו וכללה שינוי במסד הנתונים. אל תחזרו לגרסה קודמת עדיין ואל תשנו את מסד הנתונים. תסבירו מה הקוד הישן מצפה לו, איך מסד הנתונים נראה עכשיו, ואיזה מהשלושה הכי בטוח: חזרה לגרסה קודמת, תיקון קדימה או שחזור.
גרסה עם סעיפים לסימון והנחיות להעתקה: https://www.vibetodev.com/he/ai-vibe-coding-website-launch-checklist
נוצר על ידי Vibe to Dev (https://www.vibetodev.com/he), קורסים למי שבונה בעזרת AI:
- Behind the Prompt: איך האפליקציה שלכם עובדת: https://www.vibetodev.com/he/courses/advanced
- Ship & Sleep: פרודקשן ל־Vibe Coders: https://www.vibetodev.com/he/courses/prod