מפתחות API, קבצי .env, צד שרת והחשש מדליפת מידע רגיש - כל אלה עלולים לבלבל מפתחים בתחילת דרכם. המאמר הזה נועד לעשות סדר, ובעיקר להראות לכם בדיוק איך ואיפה שומרים מידע רגיש בכל שלב של הפיתוח - מסביבה מקומית, דרך פלטפורמות ענן, ועד מחוללי קוד.
מה זה בכלל API ולמה צריך מפתח?
ראשי התיבות API מייצגים Application Programming Interface. בפועל, מדובר בצינור תקשורת שמאפשר לשתי תוכנות לדבר זו עם זו בשפה מוסכמת. באמצעות ממשק כזה, אפליקציה יכולה להתחבר לשירותים חיצוניים מורכבים - למשל מודלים של בינה מלאכותית, מערכות CRM או שירותי תשלום - ולהשתמש ביכולות שלהם בלי לפתח אותן מאפס.
כדי להבין את תפקידו של ה-API במבנה אפליקציה טיפוסי, אפשר לחשוב על מסעדה. צד הלקוח (Front-end) הוא אזור הישיבה, שם הלקוח מבצע פעולות כמו הזמנה. צד השרת (Back-end) הוא המטבח, המקום שבו מתבצע העיבוד מאחורי הקלעים. וה-API עצמו הוא המלצר - הגורם שלוקח את הבקשה מהלקוח, מעביר אותה למטבח, ומחזיר את התוצאה המוכנה.
כדי שאפליקציה תוכל להשתמש ב-API של שירות חיצוני, היא צריכה להזדהות באמצעות מפתח ייחודי. מפתח כזה שקול לסיסמה אישית או למספר כרטיס אשראי - כל מי שמחזיק בו יכול לבצע שימוש בשירות על חשבונכם. לכן, שמירה בטוחה של מפתחות API היא לא המלצה, אלא חובה.
שמירת מפתחות בסביבת פיתוח מקומית
כשעובדים על המחשב האישי עם כלי פיתוח כמו Cursor או קלוד קוד (Claude Code), ולפני שלב הפריסה של האפליקציה, מפתחות ה-API נשמרים בקובץ ייעודי בשם .env - קובץ טקסט פשוט שמכיל משתני סביבה. קובץ זה מחזיק מידע רגיש, ולכן אסור שייחשף או יועלה למאגרי קוד ציבוריים.
כדי למנוע העלאה בטעות של קובץ ה-.env לפלטפורמות כמו גיטהאב (GitHub), משתמשים בקובץ בשם .gitignore, שמגדיר מראש אילו קבצים לא ייכללו בהעלאה. חשוב להגדיר אותו לפני השמירה הראשונה של הפרויקט במאגר הקוד.
ניהול מפתחות בסביבת ענן
ברגע שהאפליקציה נפרסת לאוויר וצד השרת מנוהל על ידי פלטפורמת ענן כמו Supabase או גוגל קלאוד (Google Cloud), הכללים משתנים. מפתחות ה-API אינם נשמרים בתוך קוד האפליקציה ואינם מועלים לגיטהאב. במקום זאת, הניהול מתבצע באמצעות פונקציות צד שרת, הנקראות Edge Functions, שרצות מאחורי הקלעים.
בפלטפורמת Supabase, למשל, מפתחות ה-API מוזנים דרך לשונית Secrets בממשק הניהול. הקוד פונה למשתנה הסביבה, אבל הערך עצמו מאוחסן בצורה מוצפנת בפלטפורמה - לא בקוד המקור.
מפתחות בפלטפורמות פיתוח ומחוללי קוד
עבודה עם גוגל AI סטודיו (Google AI Studio)
בסביבת הפיתוח של גוגל AI סטודיו, מפתחות ה-API נשמרים תחת לשונית Secrets בממשק הניהול של הפרויקט. לאחר שהאפליקציה נפרסת לשירות ענן כמו גוגל קלאוד ראן (Google Cloud Run), פלטפורמת הענן הופכת להיות למעשה צד השרת של האפליקציה. ניהול המפתחות עובר אל ממשק הניהול של גוגל קלאוד, שם ניתן לצפות בהם ולערוך אותם.
שמירת מפתחות api בפלטפורמת Google ai studio
עבודה עם Lovable
בפלטפורמת Lovable יש שני תרחישים. כאשר צד השרת מבוסס על התשתית הפנימית של הפלטפורמה, המפתחות מנוהלים בתוך הממשק תחת לשונית Secrets - נגישה דרך סמל הענן בממשק. לעומת זאת, כאשר הפרויקט מחובר לצד שרת חיצוני כמו סופאבייס, המפתחות חייבים להיות מוזנים ישירות בממשק של סופאבייס, דרך Edge Functions ולשונית Secrets. חשוב שלא לשמור אותם בקוד המקור של הפרויקט.
מפתחות api ב-Loveable
עקרונות יסוד לניהול בטוח
כמה כללי ברזל שכדאי להטמיע בכל פרויקט, בכל שלב:
הפרדה מוחלטת מהקוד
מפתחות API, סיסמאות והרשאות לעולם אינם נכתבים בגוף קוד המקור של האפליקציה. הקוד קורא משתנה סביבה, אבל הערך הרגיש עצמו חי במערכת הפריסה או במנהל הסודות (Secret Manager).
הרשאה מינימלית
כל מפתח צריך לקבל רק את ההרשאות המצומצמות ביותר שנדרשות לתפקודו. אין להשתמש במפתח ראשי (master key) לכל הפעולות.
רוטציה קבועה
כאשר מישהו עוזב פרויקט או שיש חשש לדליפה, יש לבצע החלפה מידית של כל המפתחות הרלוונטיים.
הגדרת תקרת הוצאות
שלב קריטי שרבים מדלגים עליו. חובה להגדיר מגבלת הוצאה חודשית בממשק הניהול של ספק ה-API, כדי למנוע חיובים בלתי צפויים במקרה של דליפת מפתח או שימוש חריג.
שמירה על דיסקרטיות
לעולם אין לשתף ערכי מפתחות אמיתיים בצ'אט, בדוא"ל או במסמך פתוח. גם לא "רק לרגע" או "רק בשביל בדיקה".
בסופו של דבר, ניהול מפתחות API הוא לא נושא טכני מורכב - זה בעיקר עניין של משמעת. קובץ .env בסביבה מקומית, לשונית Secrets בענן, ושתי דקות להגדרת תקרת הוצאות. שלושה צעדים פשוטים שחוסכים כאבי ראש יקרים.
