משתני סביבה בפרונטאנד - למה זה שונה מבקאנד

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

למה כל מה שבצד הלקוח הוא ציבורי

כשאתם בונים אפליקציית פרונטאנד עם כלי בנייה, משתני סביבה שאתם מגדירים לא נשארים "בסביבה" בזמן ריצה כמו בשרת. הם נקראים בזמן הבנייה, ונארזים ישירות לתוך קובצי הג'אווהסקריפט הסופיים כטקסט רגיל. זה אומר שכל ערך שהגדרתם כמשתנה סביבה בצד הלקוח, יושב בתוך הקוד שנשלח לדפדפן של כל מבקר באתר, וכל אחד יכול לפתוח את כלי הפיתוח, לחפש בקבצים, ולמצוא אותו בלי שום מאמץ מיוחד. אין כאן שום מנגנון הצפנה או הסתרה, זה פשוט טקסט גלוי בתוך קובץ שהדפדפן מוריד.

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

קידומת ככלי בטיחות

כלי בנייה מודרניים מטפלים בזה בגישה חכמה: הם חושפים לקוד הלקוח רק משתני סביבה ששמם מתחיל בקידומת מוגדרת מראש, ומתעלמים משאר משתני הסביבה שקיימים בסביבת הבנייה. לדוגמה:

VITE_API_URL=https://api.example.com
DATABASE_PASSWORD=super-secret-value

במקרה הזה, רק VITE_API_URL ייארז לקוד הלקוח, כי הוא נושא את הקידומת המוכרת. DATABASE_PASSWORD יישאר מחוץ לחבילה, פשוט כי כלי הבנייה לא מכיר בו ככזה שמותר לחשוף. זו לא הגנה מושלמת, כי היא מסתמכת על כך שמישהו לא ייתן בטעות לערך רגיש שם עם הקידומת הנכונה, אבל היא כן יוצרת מחסום ברירת מחדל: אם לא ציינתם במפורש שרוצים לחשוף ערך מסוים, הוא לא נחשף.

קבצי env נפרדים לכל סביבה

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

.env.development
.env.staging
.env.production

כתובת ה-API בפיתוח מקומי מצביעה לשרת מקומי, ובייצור מצביעה לשרת האמיתי, וכלי הבנייה בוחר אוטומטית איזה קובץ לטעון לפי הפקודה שהרצתם. חשוב לשים לב שקובצי env עם ערכים אמיתיים לא אמורים להיכנס לבקרת גרסאות, ורק קובץ לדוגמה עם שמות המשתנים בלי הערכים עצמם צריך להישמר שם, כדי שכל מפתח חדש בפרויקט ידע אילו משתנים נדרשים בלי לחשוף ערכים אמיתיים.

ההבדל התפיסתי מבקאנד

בבקאנד, ניהול סודות זה נושא רחב בפני עצמו, עם כלים ייעודיים לניהול והחלפה של מפתחות רגישים בזמן ריצה. בפרונטאנד השאלה פשוטה יותר, אבל דורשת שינוי מחשבה מוחלט: תתייחסו לכל דבר שנארז לקוד הלקוח כאילו הוא כבר פורסם באינטרנט הפתוח, כי מבחינה מעשית הוא כן. זה לא אומר שמשתני סביבה בפרונטאנד חסרי תועלת, בדיוק להפך, הם מצוינים לניהול הגדרות שמשתנות בין סביבות, כמו כתובות API ציבוריות או דגלי פיצ'רים. פשוט אל תבלבלו בין "נוח לנהל דרך משתנה סביבה" לבין "בטוח לשמור כסוד".

בקורס צד לקוח מסבירים איך לבנות תהליך עבודה נכון בין סביבות פיתוח וייצור, כולל ההבדלים החשובים האלה בין מה שמותר ומה שאסור לחשוף בצד הלקוח.

לסיכום

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

אם נתקלתם במקרה שבו לא הייתם בטוחים אם ערך מסוים בטוח לחשוף בצד הלקוח, אשמח לשמוע ולדבר על זה.

הצטרפו לקהילה בדיסקורד