פיתוח אפליקציות באמצעות Base44 : מגבלות ואילוצים שיש לשקול (אבטחה, פרטיות, ביצועים ושליטה)

פורסם ב 2 בספטמבר 2025 ¬ 7:37Tamir Gefen

הפתרון של Base44 הפך את המעבר מרעיון לאפליקציה פועלת למהיר באופן מדהים.
חוויית ה- AI של "chat לבנייה", ה-backend המשולב והאירוח המיידי (SaaS) מקצרים את המרחק בין הדרישות למוצר עובד. המהירות הזו משכנעת – אך היא מגיעה עם פשרות.
אם אתם מתלבטים אם לפתח על Base44 (לעומת Self-hosted [אירוח עצמי]), כדאי להבין את מגבלות הפלטפורמה בארבעה תחומים:

אבטחה, פרטיות ותאימות (Compliance), ביצועים ומכסות (Quotas), ושליטה/ניידות.
מאמר זה ממפה את המגבלות הללו ע"פ תיעוד של Base44 עצמה וגופי מחקר חיצוניים, וכן מבוסס ידע נצבר של הקבוצה שלנו בשימוש במוצר וכיועצי DevOps / DevSecOps / Cloud / AppSec (תשתית קוד מאובטחת וענן) בכדי שתוכלו לקבל החלטה מושכלת עבור האפליקציה שלכם.

1) מגבלות אבטחה בבנייה על פלטפורמה מנוהלת ומרובת-לקוחות (Multi-tenant)

פלטפורמה משותפת = גורל משותף. כמו רוב בוני ה-SaaS, גם Base44 מריצה את האפליקציות שלכם על תשתית משותפת. המשמעות היא שפגם ברמת הפלטפורמה עלול להשפיע על אפליקציות של לקוחות רבים, ובבת אחת.
בסוף יולי 2025, חברת המחקר Wiz חשפה פרצת אימות קריטית ב-Base44 שאפשרה לכל מי שהכיר app_id פומבי ולא סודי לרשום ולאמת משתמש עבור אפליקציות פרטיות – תוך עקיפת SSO ובקרות אימות אחרות. חברת Wix (הבעלים של Base44 מאז יוני 2025) תיקנה את הבעיה תוך 24 שעות מהחשיפה ודיווחה כי לא נמצאו עדויות לניצול לרעה, אך האירוע ממחיש את הסיכון המערכתי הנלווה לפלטפורמות פיתוח מרובות-לקוחות.
יכולות אימות משתנות לפי תוכנית. Base44 תומכת באימייל/סיסמה, התחברות חברתית, הזמנות ו-SSO -אך SSO מוגבל כיום לתוכנית ה-Elite. אם מודל האבטחה שלכם נשען על אכיפת SSO בכל מקום (נורמה בארגונים), תכננו מראש את המנוי המתאים או חלופה (אנו מציעים גם תמיכת SSO באמצעות הכלי הפופולרי Keycloak – פרטים כאן).
דפים ציבוריים מול פרטיים: עדיין אין אפשרות היברידית. כיום לא ניתן לשלב דפים ציבוריים ופרטיים בתוך אפליקציית Base44 יחידה. התיעוד מציע פתרון עוקף (אפליקציית "דף נחיתה ציבורי" נפרדת המקשרת לאפליקציה הפרטית שלכם), אך זה עדיין דוחף אתכם לתבנית של שתי אפליקציות שצריך לנהל בזהירות. עבור מערכות מסוימות, זה הופך לאילוץ ארכיטקטוני ולמלכודת אבטחה פוטנציאלית אם המעבר בין האפליקציות אינו מאובטח היטב.
עליכם להגדיר אבטחה ברמת השורה (RLS) כראוי. Base44 מספקת בקרות RLS ואף מדגישה במפורש תרחישי שימוש מרובי-לקוחות (למשל, כל לקוח (tenant) צריך לראות רק את הנתונים שלו)¹⁷. זה טוב – אך זה גם אומר שהפרדת הנתונים היא באחריותכם התפעולית בתוך המוצר. תצורה שגויה של RLS היא נתיב סיכון קלאסי ב-SaaS. פיצ'ר ה-"Security Check" של Base44 יכול לזהות אוטומטית כללי RLS מתירניים ולהציע תיקונים, אך עדיין עליכם לוודא את מה שהמסייע משנה.
סודות (Secrets) ונקודות קצה ב-backend עלולים להיחשף אם החיבורים שגויים. פיצ'ר ה-Security Check סורק גם אחר מפתחות API חשופים בקוד ה-frontend ופונקציות backend לא מאומתות, שתי תבניות שיכולות להיווצר כשבונים מהר. זוהי הגנה שימושית, אך היא גם תזכורת לכך שסיכונים מסוימים נוצרים מבחירות של המפתח—ולא רק מבאגים בפלטפורמה.
התנאים מעבירים חלק מהסיכון אליכם. תנאי השירות של Base44 מבהירים שהשימוש שלכם הוא "כפי שהוא" ("as is"), עם הסרת אחריות רחבה בנושאי אבטחה וזמינות, כולל ניסוח מפורש שהחברה אינה מתחייבת לאבטחה או לדיוק, ושאתם אחראים להעריך את הפלט שנוצר ועל כל מידע שהמשתמשים שלכם חולקים איתו. עבור סביבות מפוקחות/בסיכון גבוה (למשל, רפואה, תשתית קריטית), תנאי השירות אוסרים במפורש על שימוש כזה ללא רישוי מתאים. זה לא חריג עבור SaaS, אך עבור צוותים מסוימים זהו תנאי סף שאינו מאפשר שימוש.

שורה תחתונה בנושא אבטחה: Base44 מציעה בקרות מועילות (RLS, SSO בתוכניות הגבוהות, Security Check), אך המודל מרובה-הלקוחות יחד עם התקרית מיולי 2025 מראים שעמדת האבטחה של האפליקציה שלכם קשורה לתקינות הפלטפורמה. אם אתם דורשים הבטחות חזקות סביב אימות, בידוד נתונים ובקרת שינויים, ייתכן שתעדיפו גישה באירוח עצמי שבה אתם הבעלים של כל משטח התקיפה (והאחריות הנלווית לכך).

2) מגבלות פרטיות ותאימות (Compliance) שיש לקחת בחשבון

העברות נתונים בינלאומיות ועיבוד על ידי צדדים שלישיים. מדיניות הפרטיות של Base44 מציינת כי מכיוון שהחברה פועלת גלובלית, ייתכן שנתונים אישיים יועברו למדינות אחרות²⁸. היא גם מתארת שיתוף עם

ספקים חיצוניים ויצירת מטא-דאטה אנונימי/מצטבר. אם עליכם לשמור נתונים בתחומי שיפוט ספציפיים (למשל, תושבות באיחוד האירופי בלבד), תצטרכו לאשר את קיום בקרות מיקום הנתונים ולהשיג נספח עיבוד נתונים (DPA); ³⁰המדיניות מתייחסת לכניסה ל-DPA "במידה הנדרשת על פי חוק". התיעוד הציבורי אינו מפרסם אפשרות לבחירת אזורי תושבות נתונים (data residency) על ידי הלקוח.

מגבלות על נתונים רגישים. תנאי השירות מציינים במפורש שאסור לכם להעלות נתונים מקטגוריות מיוחדות הדורשות טיפול ייחודי (למשל, מידע בריאותי מוגן (PHI) או נתוני כרטיסי אשראי) אלא אם כן יש לכם הסכם כתוב מראש עם Base44 ו"ההסכם המתאים בתוקף". אם מפת הדרכים שלכם כוללת נתונים מפוקחים, התייחסו לכך כדרישת סף.
קובצי Cookie/מעקב שיווקי כברירת מחדל. מדיניות הפרטיות כוללת שימוש בקובצי Cookie ובכלי ניתוח (למשל, Google Analytics) ומציינת אפשרות ליצירת קשר שיווקי הקשור למזהים. עבור אפליקציות פנימיות עם הבטחות פרטיות מחמירות לעובדים או ללקוחות, ייתכן שתצטרכו לבדוק ולהתאים את התנהגות קובצי ה-Cookie והסכמות המשתמשים.
שירותי בינה מלאכותית של צד שלישי נמצאים מחוץ לשליטת Base44. תנאי השירות מדגישים כי ספקי מודלי AI הם שירותי צד שלישי שפעולתם יכולה להשפיע על האיכות והאמינות. אם הפלט של האפליקציה שלכם רגיש, זהו שיקול של פרטיות ואבטחת מידע: תצטרכו חוזים וניטור ברמת הספק, מעבר ל- Base44.
חלונות הזמן לסיום התקשרות (Offboarding) צפופים. עם סיום ההתקשרות, ללקוחות יש חלון של 15 יום לבקש ולקבל את נתוני הלקוח ש-Base44 מחזיקה (או לבקש מחיקה). זה סביר, אך דורש תכנון—במיוחד אם אתם פועלים תחת חובות שמירת מידע או צווי שימור משפטיים.

שורה תחתונה בנושא פרטיות: ניתן לבנות אפליקציות המכבדות פרטיות על Base44, אך עליכם להתאים את צורכי תחום השיפוט, הנתונים הרגישים וסיום ההתקשרות שלכם למדיניות הפלטפורמה ולרמת התוכנית שלכם. עבור תוכניות תאימות או תושבות נתונים מחמירות, ודאו את תנאי ה-DPA וכל בקרת מיקום נתונים מול Base44 לפני שאתם מכניסים נתונים אמיתיים.

3) מגבלות ביצועים ומכסות בסביבת ריצה משותפת הנמדדת בקרדיטים

סיכון "שכן רועש" הוא אינהרנטי ב-SaaS מרובה-לקוחות. בסביבות משותפות, העומס של לקוח אחד יכול להשפיע על אחר—בעיית ה"שכן הרועש" הקלאסית. SaaS עם ארכיטקטורה טובה ממזער זאת, אך אתם עדיין יורשים את אסטרטגיית בידוד המשאבים של הספק. אם זמני תגובה (latency) צפויים תחת עומס פתאומי הם דרישה קשיחה, אירוח עצמי או סביבה ייעודית (dedicated tenancy) לרוב מנצחים⁴⁶.
הפיתוח וזמן הריצה שלכם נשלטים על ידי קרדיטים ומגבלות תוכנית. Base44 משתמשת בקרדיטים להודעות (לאינטראקציות בזמן בנייה/עם המודל) ובקרדיטים לאינטגרציות (לפעולות בזמן ריצה כגון קריאות LLM, פעולות קבצים, אימיילים, שאילתות DB). דף התמחור מציין שכל בקשת אינטגרציה עולה קרדיט אחד, ואם תגיעו למכסות היומיות/חודשיות, ההודעות ובקשות האינטגרציה שלכם יושהו עד לחלון הבא או עד לשדרוג. עבור אפליקציות בסביבת ייצור (production), זה יוצר מכסה קשיחה שעליכם לאמוד באופן שמרני כדי למנוע כשלים הנראים למשתמש. תנאי השירות גם שומרים ל-Base44 את הזכות לשנות את מגבלות השימוש.
שירותים חיצוניים יכולים להגביל אתכם (rate-limit) לפני Base44. מדריך האינטגרציות של Base44 מציין מגבלות קצב של ספקים חיצוניים (למשל, OpenAI, שערי אימייל/SMS) כגורם כשל נפוץ. בפועל, יש לכם שתי תקרות: מגבלות הקצב של הספק וקרדיטים האינטגרציה של Base44. תרצו לתכנן מנגנוני התמודדות עם כשלים (graceful degradation) וניסיונות חוזרים (backoff).
יכולות ניטור (Observability) וכוונון הן "בסגנון פלטפורמה". Base44 חושפת מוניטור פעילות לספירת בקשות ומגיעה עם backend/מסד נתונים משולב. מה שאתם לא מקבלים זה שליטה גולמית בתשתית: גודל המכונות (instance), בחירת מנוע/גרסת מסד הנתונים, כוונון מאגר החיבורים (connection pool), או עיצוב רשת ישיר. עבור אפליקציות רבות, זהו יתרון (פחות כפתורים לכוונן); עבור עומסי עבודה רגישים לזמני תגובה, זוהי מגבלה.

שורה תחתונה בנושא ביצועים: רוב הכלים הפנימיים והפורטלים עם תעבורה מתונה יפעלו היטב על Base44.
אם האפליקציה שלכם רגישה לזמני תגובה, חווה קפיצות חדות בתעבורה, או חייבת להבטיח יעדי רמת שירות (SLOs) מחמירים תחת עומס פתאומי, השילוב של סביבה משותפת ומכסות קשיחות צריך לדחוף אתכם לבדיקות עומסים, תכנון מרווחי ביטחון ברמת התוכנית, או לפריסה ייעודית/באירוח עצמי שבה אתם שולטים במעטפת הגדילה (scaling).

4) שליטה, ניידות ונעילה (lock-in): מה אתם יכולים לקחת אתכם (ומה לא)

אתם יכולים לייצא את הקוד שלכם – אך לא את כל הפלטפורמה המנוהלת.
הממשק של Base44 כולל אפשרות "See all files" → ייצוא ל-ZIP או דחיפה ל-GitHub, שזה בדיוק מה שרוצים עבור ניידות, בקרת גרסאות וסקירת אבטחה. עם זאת, זכרו שקבצים מיוצאים אינם משחזרים באופן קסום את

השירותים המנוהלים של Base44 (אימות, אכיפת RLS, ממשקי API שנוצרו אוטומטית, מסד נתונים משולב). אם תעזבו את הפלטפורמה, תצטרכו להעביר את הרכיבים הללו לפלטפורמה חדשה על ה-stack שלכם (למשל, ספק האימות שלכם, מסד הנתונים שלכם, ה-API gateway שלכם).

ייצוא ל-GitHub מוגבל לפי תוכנית. דף התמחור מציג את האינטגרציה עם GitHub כיכולת של תוכנית ה-Builder ומעלה. אם ייצוא/סנכרון למאגרים שלכם הוא דרישת סף עבורכם, תכננו בהתאם.
ניידות ה-backend מתפתחת. שרשורי משוב בקהילה מבקשים "ייצוא ל-GitHub עם ממשקי API של ה-backend"—מה שמרמז שכיום, חלקים מה-backend נשארים מנוהלים על ידי הפלטפורמה ודורשים החלפה אם תארחו בעצמכם. זה לא חריג עבור פלטפורמות no/low-code, אך כדאי לבדוק את הייצוא בשלב מוקדם, לקרוא את המאגר שנוצר, ולמפות כל יכולת שמספקת Base44 למקבילה בסביבת הריצה היעודית שלכם.
אימות ובקרת גישה הם פיצ'רים של המוצר, לא רכיבים בסיסיים שאתם שולטים בהם. אימות ו-RLS הם פיצ'רים מרכזיים במוצר ב-Base44. זה מאיץ את הפיתוח, אך זה גם אומר שמודל האבטחה של האפליקציה שלכם צמוד להפשטות (abstractions) של Base44 (למשל, הסמנטיקה המדויקת של הגדרות פרטיות, ברירות מחדל של תפקידים, ותמיכה ב-SSO). אם תעזבו, תצטרכו לממש מחדש את הזרימות הללו על פלטפורמת הזהויות שלכם ולאכוף RLS ברמת מסד הנתונים או השירות.
משמעת בתהליך סיום ההתקשרות חשובה. מעבר לייצוא קוד, תכננו כיצד תחלצו נתונים ותחליפו תלויות במהלך המעבר. תנאי השירות נותנים לכם 15 יום לאחר סיום ההתקשרות לבקש נתונים בפורמט סטנדרטי; החמצה של חלון זה עלולה להיות כואבת. בנו ספרי נהלים (runbooks) לייצוא, העברת נתונים ושינויי DNS/דומיין (Base44 תומכת בדומיינים מותאמים אישית).

שורה תחתונה בנושא שליטה:
Base44 מפחיתה את העומס הקוגניטיבי על ידי אריזת תשתית ותבניות אבטחה – אך האריזה הזו היא בדיוק מה שתצטרכו להחליף כדי לארח בעצמכם. אתם יכולים להיות הבעלים של הקוד, אך אתם לא הבעלים של סביבת הריצה המנוהלת, וחלק מהיכולות מוגבלות לפי תוכנית.
אם אתם צופים תקופה קצרה על Base44 ואחריה מעבר ל-stack שלכם, הוכיחו את נתיב הייצוא בשלב מוקדם והגבילו את השימוש ביכולות לאלו שאתם יכולים לשכפל.

הנחיות מעשיות אם אתם משתמשים ב- Base44 :

התייחסו ל-RLS כחובה, לא כאופציה. התחילו מגישת "דחייה כברירת מחדל" (deny-by-default); השתמשו ב-Security Check כדי לתפוס כללים מתירניים ופונקציות לא מאומתות, ולאחר מכן בדקו כל תיקון "בלחיצה אחת" לפני החלתו.
אכפו את מודל הזהויות שלכם. אם אתם דורשים SSO, התחילו בתוכנית שכוללת אותו ונעלו את הגדרות הפרטיות; הימנעו מ"ציבורי עם התחברות" עבור מערכות המטפלות בנתונים פנימיים או רגישים.
התייחסו למכסות כאל ארכיטקטורה, לא כחיוב. חשבו את צורכי קרדיטי ההודעות והאינטגרציות הן לזמן הבנייה והן לזמן הריצה, כללו מרווח ביטחון, ותקצבו עבור קפיצות עומס (או טפלו בכשלים בחן אם הגעתם למגבלות).
הקשיחו אינטגרציות. צפו למגבלות קצב חיצוניות ולכשלים חלקיים. הוסיפו ניסיונות חוזרים/backoff והצגת סטטוס ברור למשתמש.
תרגלו את הייצוא. דחפו אפליקציה עובדת ל-GitHub ובצעו תרגיל "הרם והזז" (lift and shift) של יום אחד לאירוח עצמי מינימלי (אפילו רק שיבוט לסביבת בדיקות). תעדו אילו שירותי Base44 נאלצתם להחליף (אימות, DB, אימייל, אחסון קבצים).
עקבו אחר תקריות בפלטפורמה. פרצת האימות מיולי 2025 תוקנה במהירות, אך היא מדגישה את רדיוס הפגיעה ברמת הפלטפורמה. הירשמו לערוצי האבטחה של Base44/Wix ושמרו על בקרות מפצות (למשל, מאגרי נתונים נפרדים, הרשאות מינימליות).

מתי Base44 היא התאמה טובה, ומתי עדיף לארח עצמאית (Self-hosted) ?

התאמה טובה: כלים פנימיים, פורטלים למשרד האחורי (back-office), לוחות מחוונים (dashboards) של נתונים, ופורטלי לקוחות עם צורכי תאימות מתונים—במיוחד כאשר זמן היציאה לשוק (time-to-value) הוא קריטי ואתם יכולים להתקיים בתוך מכסות התוכנית ותבניות הפלטפורמה. יכולות ה-RLS, האימות וה-Security Check של Base44 יכולות לשמור עליכם אם תשתמשו בהן בכוונה.

העדיפו אירוח עצמי: מערכות הדורשות אכיפת SSO בכל מקום, נראות דפים היברידית (ציבורי + פרטי באפליקציה אחת), זמני תגובה נמוכים וצפויים תחת עומס פתאומי, תושבות נתונים באזור ספציפי, או כאשר תוכנית האבטחה שלכם דורשת שליטה מלאה על אימות, מאגרי נתונים, והקשחת סביבת הריצה. הפגיעות האחרונה והסרת האחריות בתנאי השירות לא יפסלו את Base44 באופן אוטומטי, אך הן צריכות לדחוף צוותים עם דרישות אבטחה גבוהות לכיוון

סביבות ייעודיות או stacks בניהול עצמי.

סיכום מהיר (מה שהתיעוד והמחקר אומרים)

ייצוא קוד: ייצוא מובנה ל-ZIP/GitHub; אינטגרציית GitHub בתוכנית Builder ומעלה. שימושי למניעת נעילה, אך עליכם לבנות מחדש שירותים מנוהלים אם תעזבו.
בקרות אימות ופרטיות: אימייל/חברתי/SSO (SSO ב-Elite), אין דפים היברידיים (ציבורי/פרטי) באפליקציה אחת כיום.
בידוד נתונים: RLS הוא רכיב מרכזי; סורק האבטחה עוזר לתפוס כללים מתירניים, סודות חשופים או פונקציות לא מאומתות.
מכסות: קרדיטים להודעות ואינטגרציות;

קרדיט 1 לכל בקשת אינטגרציה; הגעה למגבלות משהה את השימוש עד לאיפוס/שדרוג; Base44 יכולה לשנות את מגבלות התוכנית לפי תנאי השירות.

סיכון ברמת הפלטפורמה: פרצת האימות מיולי 2025 אפשרה הרשמה לאפליקציות פרטיות עם app_id ציבורי (תוקן כעת). תזכורת לכך שפלטפורמות מרובות-לקוחות נושאות סיכון משותף.
עמדת פרטיות: העברות בינלאומיות אפשריות; DPA זמין "כנדרש"; נתונים רגישים דורשים הסכם כתוב מראש; קובצי Cookie/ניתוח עבור הפלטפורמה והאתר.

מחשבה אחרונה:

כוח העל של Base44 הוא המהירות. אתם מוותרים על מידה מסוימת של וודאות באבטחה/תאימות, צפיות בביצועים, ושליטה ברמה הנמוכה תמורת המהירות הזו. עבור מוצרים וצוותים רבים, זוהי עסקה מצוינת. עבור עומסי עבודה עם דרישות אבטחה גבוהות או רגולציה הדוקה, תרצו (א) להריץ את Base44 עם תבניות קפדניות, מכסות ברורות ויכולות מדורגות (כמו SSO), או (ב) לייצא את הקוד ולארח עצמאית, תוך החלפת הרכיבים המנוהלים של Base44 במקבילות משלכם. החדשות הטובות הן שאתם יכולים לבחון את שני הנתיבים היום:

ייצאו אפליקציה עובדת והעריכו מה יידרש כדי להריץ אותה על התשתית שלכם לפני שתתחייבו.