מפתח API סודי באפליקציית Expo: מה צריך להגן?

משתנה סביבה הוא לא בהכרח סוד

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

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

הטבלה הבאה היא כלי לתכנון, לא ביקורת של האפליקציה שלך.

רכיב	איפה לשים אותו	מה לבדוק
הכתובת הציבורית של ה-backend	בהגדרות של האפליקציה	שהיא מצביעה על הסביבה הנכונה.
מפתח Supabase publishable, או מפתח anon הישן	באפליקציה, אם ההרשאות מוגדרות כמו שצריך	שחוקי הנתונים באמת חוסמים גישה לחשבון של משתמש אחר.
מפתח Supabase secret או service_role	בשרת בלבד	שהוא לא מופיע ב-bundle של המובייל ולא בלוגים שהלקוח יכול לגשת אליהם.
מפתח סודי של ספק בינה מלאכותית	בשרת בלבד	שהאפליקציה קוראת לשרת שלך, והוא בודק את המשתמש ואת המגבלות לפני הפנייה לספק.

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

דוגמה: אפליקציה דמיונית של יומן קריאה

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

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

סינון בממשק, כמו "להציג את ההערות של המשתמש המחובר", משפר את התצוגה. אבל ההרשאה צריכה להיאכף גם בצד הנתונים. ב-Supabase, חוקי Row Level Security מאפשרים להגביל את השורות הנגישות לפי ה-session. Supabase ממליצים להפעיל אותם בטבלאות שחשופות דרך ה-API ומסבירים את מדיניות הקריאה והכתיבה. מקור: Row Level Security.

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

תסריט הבדיקה עם שני חשבונות בדיקה

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

1. לקרוא את ההערה שלך. חשבון A מוצא את הערה A.
2. לקרוא את ההערה של B מתוך A. הבקשה לא חושפת את התוכן הפרטי שלה.
3. לערוך את ההערה של B מתוך A. השרת דוחה, והערה B נשארת בלי שינוי.
4. ליצור בשם B מתוך A. השרת דוחה את השיוך הזה.
5. לקרוא בלי session. לא חוזר שום תוכן פרטי.
6. לפתוח את הקובץ הפרטי של B מתוך A. הקובץ לא נגיש.

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

להעביר קריאה בתשלום דרך השרת שלך

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

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

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

מה אפשר לבקש מעוזר הקוד שלך

הנה הנחיית סקירה שאפשר להתאים ל-repo שלך, בלי להדביק בה את הערכים הסודיים:

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

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

לפני שממשיכים עם האפליקציה

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

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

שאלות נפוצות

איפה לשים מפתח API סודי באפליקציית Expo?

בשרת שלך, אף פעם לא באפליקציה. מפתח Supabase secret או service_role, וגם המפתח הסודי של ספק בינה מלאכותית, צריכים להישאר בצד השרת בלבד. האפליקציה קוראת לשרת שלך, והוא בודק את המשתמש ואת המגבלות לפני שהוא פונה לספק. תוודא שאף אחד מהמפתחות האלה לא מופיע ב-bundle של המובייל ולא בלוגים שהלקוח יכול לגשת אליהם.

האם קובץ .env מגן על מפתח ה-API שלי ב-Expo?

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

מה ההבדל בין מפתח API ציבורי למפתח סודי?

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

איך קוראים ל-API של בינה מלאכותית מאפליקציית Expo בלי לחשוף את המפתח?

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

איך לבדוק שכל משתמש רואה רק את הנתונים שלו?

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

איך לבקש מבינה מלאכותית לבדוק את המפתחות של האפליקציה שלי?

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