הנחיות אבטחה בפלטפורמה של מפות Google

באפליקציות ובפרויקטים שמשתמשים בממשקי ה-API ובערכות ה-SDK של Google Maps Platform, חובה להשתמש במפתחות API או ב-OAuth 2.0 (אם יש תמיכה) כדי לאמת את עצמם.

השיטות המומלצות האלה מראות איך לאבטח את הגישה לפלטפורמה של מפות Google.

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

בנוסף להגבלות על אפליקציות ומפתחות API, צריך לפעול לפי נוהלי האבטחה שרלוונטיים למוצרים ספציפיים של Google Maps Platform. לדוגמה, ראו את Maps JavaScript API בקטע הגבלות מומלצות על אפליקציות ועל ממשקי API בהמשך.

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

מידע נוסף על חתימות דיגיטליות שנתמכות על ידי Maps Static API ו-Street View Static API זמין במדריך בנושא חתימות דיגיטליות.

שיטות מומלצות

כדי לשפר את האבטחה ולמנוע חיובים על שימוש לא מורשה, כדאי לפעול לפי השיטות המומלצות הבאות לאבטחת ממשקי API בכל ממשקי ה-API, ערכות ה-SDK או השירותים של Google Maps Platform:

מומלץ לכל השימושים במפתחות API

הגבלת מפתחות ה-API

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

מחיקת מפתחות API שלא בשימוש

בדיקת השימוש במפתח ה-API

היזהרו כשאתם מחליפים מפתחות API

פיצול השימוש בצד הלקוח ובצד השרת לפרויקטים נפרדים

השבתת שירותים שלא בשימוש

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

שימוש בערכות SDK בצד הלקוח

אבטחת קריאות לשירותי אינטרנט בצד הלקוח

המלצות נוספות לאתרים או לאפליקציות בצד הלקוח שמשתמשים בממשקי API סטטיים לאינטרנט

הגנה על השימוש ב-Static Web API

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

הגנה על מפתחות API של שירות אינטרנט

שימוש ב-OAuth לאפליקציות בצד השרת

אם אתם מגבילים או מחליפים מפתח API שנמצא בשימוש

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

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

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

  איך עוברים למספר מפתחות API

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

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

  מידע נוסף זמין במאמר טיפול בשימוש לא מורשה במפתח API.

מידע נוסף

הגבלות מומלצות על אפליקציות ו-API

הגבלת מפתחות ה-API

השיטה המומלצת היא תמיד להגביל את מפתחות ה-API באמצעות סוג אחד של הגבלות על אפליקציות והגבלה אחת או יותר על ממשקי API. בקטע המלצות להגבלות על אפליקציות ועל ממשקי API שבהמשך מפורטות הצעות להגבלות לפי API,‏ SDK או שירות JavaScript.

• הגבלות על אפליקציות אתם יכולים להגביל את השימוש במפתח API לפלטפורמות ספציפיות: אפליקציות ל-Android או ל-iOS, או אתרים ספציפיים לאפליקציות בצד הלקוח, או כתובות IP ספציפיות או רשתות משנה של CIDR לאפליקציות בצד השרת שמנפיקות קריאות ל-API בארכיטקטורת REST של שירות אינטרנט.

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

• הגבלות על ממשקי API: אתם יכולים להגביל את ממשקי ה-API, ערכות ה-SDK או השירותים של Google Maps Platform שבהם אפשר להשתמש במפתח ה-API. הגבלות על ממשקי API מאפשרות רק בקשות לממשקי ה-API ולערכות ה-SDK שאתם מציינים. לכל מפתח API אפשר לציין כמה הגבלות שרוצים. רשימת ממשקי ה-API הזמינים כוללת את כל ממשקי ה-API שמופעלים בפרויקט.

הגדרת הגבלה על אפליקציות למפתח API

1. פותחים את הדף Google Maps Platform Credentials במסוף Google Cloud.

2. בוחרים את מפתח ה-API שרוצים להגביל.

3. בקטע הגבלות מפתח בדף עריכת מפתח API, בוחרים באפשרות הגדרת הגבלת אפליקציה.

   

4. בוחרים אחד מסוגי ההגבלות ומספקים את המידע הנדרש בהתאם לרשימת ההגבלות.

   סוג ההגבלה	תיאור
   אתרים	מציינים אתר מפנה אחד או יותר. סכמות ה-URI של ההפניה הנתמכות באופן אוניברסלי הן https ו-http. אין ערובה לכך שסכמות אחרות יפעלו בצורה תקינה, כי מטעמי פרטיות, דפדפני אינטרנט מודרניים לא ישלחו כותרת Referer בבקשות יוצאות. תמיד צריך לספק את מחרוזת ההפניה המלאה, כולל סכמת הפרוטוקול, שם המארח והיציאה האופציונלית (למשל, https://google.com). אפשר להשתמש בתווים כלליים לחיפוש כדי לאשר את כל תת-הדומיינים. לדוגמה, ההגבלה https://*.google.com מקבלת את כל האתרים שמסתיימים ב-.google.com. חשוב להיזהר כשמאשרים מפנים עם נתיב מלא, לדוגמה, https://google.com/some/path, כי רוב דפדפני האינטרנט יסירו את הנתיב מבקשות ממקורות שונים מטעמי פרטיות.
   כתובות IP	מציינים כתובת IPv4 או IPv6 אחת או יותר, או רשתות משנה באמצעות סימון CIDR. כתובות ה-IP חייבות להתאים לכתובת המקור ששרתי Google Maps Platform מזהים. אם אתם משתמשים בתרגום כתובת רשת (NAT), הכתובת הזו בדרך כלל תואמת לכתובת ה-IP הציבורית של המכונה.
   אפליקציות ל-Android	מוסיפים את שם החבילה של Android (מהקובץ AndroidManifest.xml) ואת טביעת האצבע לאישור החתימה SHA-1 של כל אפליקציה ל-Android שרוצים לאשר. לוחצים על אפליקציות ל-Android. לוחצים על + הוספה. מזינים את שם החבילה ואת טביעת האצבע לאישור SHA-1. לדוגמה: com.example.android.mapexample BB:0D:AC:74:D3:21:E1:43:67:71:9B:62:91:AF:A1:66:6E:44:5D:75 לוחצים על שמירה. יש שני סוגים של אישורים: אישור לניפוי באגים: השתמשו בסוג האישור הזה רק באפליקציות שאתם בודקים ובקוד אחר שלא מיועד לסביבת הייצור. אל תנסו לפרסם אפליקציה שחתומה באמצעות אישור לניפוי באגים. כלי ה-SDK של Android יוצרים את האישור הזה באופן אוטומטי כשמריצים גרסת build לניפוי באגים. אישור הפצה: משתמשים באישור הזה כשמוכנים להפיץ את האפליקציה בחנות אפליקציות. כלי ה-SDK של Android יוצרים את האישור הזה כשמפעילים גרסת build להפצה. מידע נוסף על חתימת אפליקציות ואישורים ב-Android זמין במדריך לחתימת אפליקציות. אם אתם משתמשים בחתימת אפליקציות ב-Play, כדי לאחזר את טביעת האצבע לאישור החתימה, עיינו במאמר עבודה עם ספקי API. אם אתם מנהלים את מפתח החתימה שלכם, עיינו במאמר חתימה עצמית על האפליקציה או בהוראות לסביבת ה-build שלכם.
   אפליקציות ל-iOS	מוסיפים את מזהה החבילה של כל אפליקציה ל-iOS שרוצים לאשר. לוחצים על אפליקציות ל-iOS. לוחצים על + הוספה. מוסיפים את מזהה החבילה כדי לקבל בקשות מהאפליקציה ל-iOS עם המזהה הזה. לוחצים על שמירה.

   המלצות להגבלת אפליקציות מפורטות במאמר הגבלת אפליקציות מומלצת.

5. לוחצים על שמירה.

הגדרת הגבלות על ממשקי API למפתח API

1. פותחים את הדף Google Maps Platform Credentials במסוף Google Cloud.

2. בוחרים את מפתח ה-API שרוצים להגביל.

3. בדף עריכת מפתח API, בקטע הגבלות API:

   • בוחרים באפשרות Restrict key.

   • פותחים את Select APIs ובוחרים את ממשקי ה-API או ערכות ה-SDK שהאפליקציה תוכל לגשת אליהם באמצעות מפתח ה-API.

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

   

4. לוחצים על שמירה.

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

המלצות להגבלות על ממשקי API

בדיקת השימוש במפתח ה-API

אם אתם מגבילים את מפתחות ה-API אחרי שהם נוצרו, או אם אתם רוצים לראות באילו ממשקי API נעשה שימוש באמצעות מפתח מסוים כדי להגביל אותם, אתם צריכים לבדוק את השימוש במפתח ה-API. בשלבים האלה מוסבר באילו שירותים ובאילו שיטות API נעשה שימוש במפתח API. אם אתם רואים שימוש כלשהו מעבר לשירותי Google Maps Platform, בדקו אם צריך להוסיף עוד הגבלות כדי למנוע שימוש לא רצוי. כדי להחליט אילו הגבלות להחיל על מפתח ה-API, אתם יכולים להשתמש ב-Metrics Explorer במסוף Cloud של Google Maps Platform:

• זיהוי ממשקי ה-API שמשתמשים במפתח ה-API

• בחירת הסוג הנכון של הגבלת האפליקציה באמצעות Metrics Explorer

איך בודקים אילו ממשקי API משתמשים במפתח ה-API שלכם

דוחות המדדים הבאים מאפשרים לכם לקבוע אילו ממשקי API משתמשים במפתחות ה-API שלכם. אפשר להשתמש בדוחות האלה כדי:

• איך בודקים את השימוש במפתחות ה-API
• זיהוי שימוש לא צפוי
• כדי לבדוק אם אפשר למחוק בבטחה מפתח שלא נמצא בשימוש. במאמר מחיקת מפתחות API שלא בשימוש מוסבר איך למחוק מפתחות API.

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

1. נכנסים לדף Metrics explorer במסוף Google Cloud.

2. נכנסים לחשבון ובוחרים את הפרויקט שבו נמצאים מפתחות ה-API שרוצים לבדוק.

3. עוברים לדף Metrics explorer של סוג ה-API:

   • למפתחות API שמשתמשים בכל API חוץ מ-Maps Embed API: נכנסים לדף Metrics explorer.

   • למפתחות API שמשתמשים ב-Maps Embed API: נכנסים אל Metrics Explorer.

4. בודקים כל מפתח API:

   1. לוחצים על הוספת מסנן.

   2. בוחרים את התווית credential_id.

   3. בוחרים את הערך שמתאים למפתח שרוצים לבדוק.

   4. שימו לב לאילו ממשקי API משמש מפתח ה-API הזה, וודאו שהשימוש צפוי.

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

5. חוזרים על הפעולה עם כל המפתחות שנותרו.

6. הגבילו את מפתחות ה-API רק לממשקי ה-API שבהם אתם משתמשים.

7. אם זיהיתם שימוש לא מורשה, קראו את המאמר טיפול בשימוש לא מורשה במפתח API.

בחירת הסוג הנכון של הגבלת האפליקציה באמצעות Metrics explorer

אחרי שווידאתם ונקטתם את הפעולות הנדרשות כדי לוודא שמפתח ה-API משמש רק לשירותי Google Maps Platform, צריך גם לוודא שלמפתח ה-API יש את הגבלות האפליקציה הנכונות.

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

אם למפתח ה-API אין המלצות להגבלות, צריך לקבוע את סוג ההגבלה שרוצים להחיל על האפליקציה, על סמך ה-platform_type שדווח באמצעות Metrics Explorer:

1. נכנסים לדף Metrics explorer במסוף Google Cloud.

2. נכנסים לחשבון ובוחרים את הפרויקט של ממשקי ה-API שרוצים לבדוק.

3. נכנסים לדף Metrics Explorer.

4. בודקים כל מפתח API:

   1. לוחצים על הוספת מסנן.

   2. בוחרים את התווית credential_id.

   3. בוחרים את הערך שמתאים למפתח שרוצים לבדוק.

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

5. חוזרים על הפעולה עם כל המפתחות שנותרו.

6. אחרי שזיהיתם את סוג הפלטפורמה של מפתחות ה-API, אתם יכולים להחיל את הגבלת האפליקציה על platform_type:

   ‫PLATFORM_TYPE_JS : החלת הגבלות על אתרים במפתח.

   ‫PLATFORM_TYPE_ANDROID : החלת הגבלות על אפליקציות ל-Android במפתח.

   ‫PLATFORM_TYPE_IOS : החלת הגבלות על אפליקציות ל-iOS במפתח.

   ‫PLATFORM_TYPE_WEBSERVICE : יכול להיות שתצטרכו להסתמך על הגבלות של כתובות IP במפתח כדי להגביל אותו כמו שצריך.

   המלצות ל-Maps Static API ול-Street View Static API מפורטות במאמר הגנה על השימוש ב-Static Web API.

   המלצות ל-Maps Embed API מפורטות במאמר אתרים עם Maps Embed API.

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

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

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

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

החלת ההגבלות המומלצות על מפתחות API

בחלק מהפרויקטים, בעלים, עורכים ואדמינים של מפתחות API מקבלים במסוף Google Cloud הצעות להגבלות ספציפיות על מפתחות API לא מוגבלים, על סמך השימוש והפעילות שלהם ב-Google Maps Platform.

אם יש המלצות, הן מופיעות כאפשרויות שמולאו מראש בדף Google Maps Platform Credentials.

ממשקי ה-API וערכות ה-SDK של Google Maps Platform שנתמכים בהמלצות האוטומטיות

• ‫Maps JavaScript API, כולל: Directions Service (מדור קודם), Distance Matrix Service (מדור קודם), Elevation Service, Geocoding Service, Place class, Place Autocomplete Widget (חדש), Place Autocomplete Data API, Places Library, Places Service, Place Autocomplete Widget, וגם Places UI Kit

• ‫Maps Static API ו-Street View Static API

• Maps Embed API

• ‫SDK של מפות ל-Android, ‏Navigation SDK ל-Android, ‏Places SDK ל-Android ו-Places UI Kit ב-Android

• ‫SDK של מפות ל-iOS, ‏Navigation SDK ל-iOS, ‏Places SDK ל-iOS, ‏Places Swift SDK ל-iOS ו-Places UI Kit ב-iOS.

סיבות לכך שלא מוצגת המלצה, או שמוצגת המלצה חלקית

סיבות לכך שלא מוצגות המלצות

• אתם משתמשים במפתח ה-API גם בשירותים אחרים, שהם לא של Google Maps Platform, או בשירותים של Google Maps Platform שעדיין לא נתמכים בהמלצות האוטומטיות.

  אם אתם רואים שימוש בשירותים אחרים, אל תיישמו את ההמלצה לפני שתבצעו את הפעולות הבאות:

  1. ב-Metrics explorer במסוף Google Cloud, מוודאים שהשימוש ב-API לגיטימי.

  2. להוסיף ידנית את השירותים החסרים לרשימת ממשקי ה-API שצריך לאשר.

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

• מפתח ה-API לא משמש בערכות SDK או בממשקי API בצד הלקוח.

• אתם משתמשים במפתח ה-API באפליקציה או באתר עם נפח שימוש נמוך, שלא היה בהם שימוש ב-60 הימים האחרונים.

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

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

סיבות לכך שההמלצה לא מושלמת

• אתם משתמשים במפתח ה-API באפליקציה או באתר עם נפח שימוש נמוך, שלא היה בהם שימוש ב-60 הימים האחרונים.

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

  אם אתם רואים שימוש בשירותים אחרים, אל תיישמו את ההמלצה לפני שתבצעו את הפעולות הבאות:

  1. ב-Metrics explorer במסוף Google Cloud, מוודאים שהשימוש ב-API לגיטימי.

  2. להוסיף ידנית את השירותים החסרים לרשימת ממשקי ה-API שצריך לאשר.

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

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

סיבות לכך שמוצגות המלצות שלא מופיעות בתרשימים

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

• התנועה שלכם מגיעה מ-Maps Embed API. הוראות מפורטות מופיעות במאמר זיהוי ממשקי ה-API שמשתמשים במפתח ה-API.

• התנועה מהאפליקציה או מהאתר היא מחוץ לטווח התאריכים שזמין ב-Metrics Explorer במסוף Google Cloud.

כדי להחיל את ההגבלות המומלצות:

1. פותחים את הדף Google Maps Platform Credentials במסוף Google Cloud.

2. אם האפשרות החלת ההגבלות המומלצות מופיעה, לוחצים עליה.

   

3. לוחצים על Check API usage כדי לבדוק באילו שירותים משתמשים במפתח ה-API. אם מופיעים שירותים אחרים, שאינם של Google Maps Platform, עצרו ובצעו ידנית את שלבי ההמלצה שלמעלה. בקטע החלת ההגבלות המומלצות על מפתחות API מפורטים השלבים לפתרון בעיות.

4. חשוב לוודא שההגבלות שמולאו מראש תואמות לאתרים ולאפליקציות שבהם אתם מתכוונים להשתמש במפתח ה-API.

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

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

   • אם אתם צריכים עזרה נוספת לגבי ההמלצה, פנו לתמיכה.

5. לוחצים על אישור.

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

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

ערכות SDK וממשקי API בצד הלקוח

אפליקציות שמבוססות על דפדפן ו-WebView

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

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

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

הוראות לפתרון בעיות באפליקציות שמבוססות על דפדפן ו-WebView:

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

  יש תמיכה חלקית בסכמות URI אקזוטיות. אם חלקים מהאפליקציה לא פועלים בסכמת URI לא שגרתית, גם אחרי שאישרתם את המפנה הנדרש, כנראה שתצטרכו לארח את האפליקציה מרחוק בשרת ולטעון אותה דרך HTTPS (או HTTP).

  אם אתם צריכים עזרה עם סכמות URI אקזוטיות, פנו לתמיכה.

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

  אין תמיכה בסכמות URI לא שגרתיות.

אפליקציות ל-Android

משתמשים ב-Android Debug Bridge (adb) או ב-Logcat

אפליקציות ל-iOS

הצגת הודעות ביומן

אפליקציות ששולחות קריאות ישירות לשירותי אינטרנט

אם אתם משתמשים באפליקציות שקוראות ישירות לנקודות קצה של API בארכיטקטורת REST או של gRPC בפלטפורמה של מפות Google, בלי ערכת SDK של הפלטפורמה של מפות Google בצד הלקוח, קראו את ההוראות הבאות:

אפליקציות ל-Android ול-iOS

אם האפליקציה שלכם ל-Android או ל-iOS שולחת קריאות ישירות לשירותים של Google Maps Platform, בלי להשתמש באף אחת מערכות ה-SDK הזמינות של לקוחות Google Maps Platform, תוכלו לקרוא את המאמרים אפליקציות ל-Android ואפליקציות ל-iOS כדי לקבל טיפים נוספים לפתרון בעיות, ואת המאמר אבטחת קריאות לשירותי אינטרנט בצד הלקוח כדי לקבל מידע על השיטות המומלצות הנוכחיות לאבטחה בתרחישי שימוש בנייד.

אם האפליקציה מתעדת ביומן את תגובות השגיאה של Maps Platform API, ההוראות שלמעלה לערכות SDK בצד הלקוח יכולות לעזור גם בפתרון בעיות אימות.

אפליקציות בצד השרת

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

אפליקציות שמבוססות על דפדפן או על WebView

גם Maps Static API,‏ Street View Static API וממשקי API חדשים יותר של Google Maps Platform יתמכו בהגבלות על גורמים מפנים, אבל חשוב לזכור שדפדפני אינטרנט או תצוגות WebView כנראה יגבילו את הכותרת Referer ל-Origin בבקשות ממקורות שונים, וכנראה לא ישלחו אותה בכלל, למשל במשאבים עם גישה מקומית או במשאבים שמוצגים באמצעות פרוטוקולים שהם לא HTTP או HTTPS.

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

טיפים לבדיקת ההגבלות על ממשקי API

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

אם אתם לא בטוחים אילו הגבלות להחיל:

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

מחיקת מפתחות API שלא בשימוש

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

כדי למחוק מפתח API:

1. פותחים את הדף Google Maps Platform Credentials במסוף Google Cloud.

2. בוחרים את מפתח ה-API שרוצים למחוק.

3. לוחצים על הכפתור מחיקה בחלק העליון של הדף.

4. בדף Delete credential, לוחצים על Delete.

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

היזהרו כשאתם מחליפים מפתחות API

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

לפני שמחליפים מפתח API:

• קודם כל, נסו להגביל את מפתחות ה-API כמו שמתואר במאמר הגבלת מפתחות API.

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

אם אי אפשר ליישם את ההצעות הקודמות, ואתם חייבים להחליף את מפתח ה-API כדי למנוע שימוש לא מורשה, בצעו את השלבים הבאים:

1. פותחים את הדף Google Maps Platform Credentials במסוף Google Cloud.

2. פותחים את מפתח ה-API שרוצים להחליף.

3. בחלק העליון של הדף, לוחצים על החלפת מפתח.

4. אם רוצים, משנים את השם של מפתח ה-API.

5. בוחרים באפשרות יצירה.

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

אחרי שמעדכנים את האפליקציות כך שישתמשו במפתח החדש, מוחקים את המפתח הישן: לוחצים על הכפתור Delete the previous key בקטע Previous Key בדף של מפתח ה-API החדש.

מעבר למספר מפתחות API

כדי לעבור משימוש במפתח API אחד לכמה אפליקציות לשימוש במפתח API ייחודי לכל אפליקציה:

1. מזהים את האפליקציות שצריכות מפתחות חדשים:

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

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

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

פיצול השימוש בצד הלקוח ובצד השרת לפרויקטים נפרדים

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

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

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

השבתת שירותים שלא בשימוש

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

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

שימוש בערכות SDK בצד הלקוח

כשמשתמשים בערכות ה-SDK של Google Maps Platform בצד הלקוח, תמיד אפשר להחיל הגבלות מתאימות על מפתח ה-API כדי לאבטח את השימוש בשירות.

שימוש בערכות SDK בצד הלקוח גם יאפשר לכם לאמץ מנגנון אבטחה מתקדם יותר, כמו Firebase App Check בממשקי ה-API של הפלטפורמה של מפות Google שתומכים בו. פרטים נוספים זמינים במאמר שימוש ב-App Check כדי לאבטח את מפתח ה-API.

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

למידע על הזמינות של ערכות ה-SDK של Google Maps Platform בצד הלקוח בפלטפורמות שונות, ראו המלצות להגבלות על אפליקציות ועל ממשקי API.

הגנה על השימוש ב-Static Web API

ממשקי API סטטיים לאינטרנט, כמו Maps Static API ו-Street View Static API, דומים לקריאות ל-API של שירות אינטרנט.

אתם קוראים לשניהם באמצעות API בארכיטקטורת REST של HTTPS, ובדרך כלל יוצרים את כתובת ה-URL של בקשת ה-API בשרת. עם זאת, במקום להחזיר תגובת JSON, ממשקי API סטטיים לאינטרנט יוצרים תמונה שאפשר להטמיע בקוד HTML שנוצר. חשוב מכך, בדרך כלל הלקוח של משתמש הקצה, ולא השרת, הוא זה שקורא לשירות של הפלטפורמה של מפות Google.

שימוש בחתימה דיגיטלית

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

למידע נוסף על חתימות דיגיטליות, עיינו במדריך לחתימות דיגיטליות.

הגנה על סוד החתימה

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

• צרו את כתובות ה-URL של בקשות ה-API החתומות ל-Maps Static API ול-Street View Static API בצד השרת כשאתם מציגים דף אינטרנט, או בתגובה לבקשה מהאפליקציה לנייד.

  בתוכן סטטי מהאינטרנט, אפשר להשתמש בווידג'ט Sign a URL now בדף Credentials של הפלטפורמה של מפות Google במסוף Cloud.

  לתוכן מהאינטרנט דינמי, עיינו בדוגמאות הקוד הזמינות לחתימה על בקשות של כתובות URL.

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

הגנה על מפתחות API של שירותי אינטרנט

כדי להשתמש בצורה מאובטחת בממשקי ה-API ובשירותים של Google Maps Platform מאפליקציות בצד הלקוח, קראו את המאמרים שימוש ב-SDK בצד הלקוח ואבטחת קריאות לשירותי אינטרנט בצד הלקוח.

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

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

שימוש ב-OAuth לאפליקציות בצד השרת

‫OAuth 2.0 הוא תקן פתוח להענקת גישה.

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

מכיוון שלחשבון שירות יכולות להיות הרשאות רחבות מאוד, מומלץ להשתמש ב-OAuth 2.0 כדי לאשר קריאות משרת לשרת בין אפליקציות מהימנות בצד השרת של המפתח לבין השרתים של הפלטפורמה של מפות Google.

לאפליקציות בצד הלקוח שפועלות במכשירי משתמשי קצה, מומלץ להשתמש בשיטות אימות אחרות, כמו מפתחות API.

אם אתם רוצים להשתמש ב-OAuth 2.0 כדי לאשר תנועה משרת לשרת, חפשו את הנושא OAuth במאמרי העזרה של ה-API.

לדוגמה, כאן מופיע נושא OAuth של Address Validation API.

שיחות מאובטחות לשירותי אינטרנט בצד הלקוח

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

שימוש בשרת proxy

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

נקודות חשובות:

• יוצרים את הבקשות ל-Google Maps Platform בשרת ה-proxy. אל תאפשרו ללקוחות להעביר קריאות ל-API באופן שרירותי באמצעות שרת ה-proxy.

• לעבד את התגובות של Google Maps Platform בשרת ה-proxy. לסנן נתונים שהלקוח לא צריך.

למידע נוסף על שימוש בשרת proxy, ראו Living Vicariously: Using Proxy Servers with the Google Data API Client Libraries.

שיחות מאובטחות ישירות לשירותי אינטרנט לנייד

אם אתם לא יכולים להגדיר שרת proxy מאובטח לאפליקציה בצד הלקוח, אתם יכולים לאבטח את האפליקציה באופן הבא:

1. שימוש בכותרות HTTP:

   • ‫Android: משתמשים בכותרות ה-HTTP‏ X-Android-Package ו-X-Android-Cert.

   • ‫iOS: משתמשים בכותרת ה-HTTP‏ X-Ios-Bundle-Identifier.

2. מוסיפים את ההגבלות המתאימות על האפליקציה למפתח ל-Android או ל-iOS.

3. לפני ששולחים קריאות ישירות מהאפליקציה לנייד לשירות אינטרנט של API בארכיטקטורת REST בפלטפורמה של מפות Google, צריך לוודא שבקשות עם מזהי אפליקציות שגויים ל-Android או ל-iOS נדחות.

   אם נקודת הקצה שנבדקה לא תומכת בהגבלות על אפליקציות ל-Android ול-iOS, ‏ Google ממליצה בחום להשתמש בשרת proxy מאובטח בין אפליקציות הלקוח לנייד לבין נקודת הקצה של שירות האינטרנט של Google Maps Platform.

טיפים לאפליקציות ל-Android:

• לפני שמשלבים את האפליקציה ל-Android עם שירותי Google Maps Platform, צריך לוודא שמזהה האפליקציה (שנקרא גם שם החבילה) בפורמט הנכון. פרטים נוספים זמינים במאמר הגדרת מודול האפליקציה במסמכי התיעוד של Android.

• כדי להעביר את X-Android-Package ישירות מהאפליקציה, צריך לחפש אותו באופן פרוגרמטי באמצעות Context.getPackageName().

• כדי להעביר את X-Android-Cert ישירות מהאפליקציות, מחשבים את טביעת האצבע הנדרשת מסוג SHA-1 של אישורי החתימה של האפליקציה, שאפשר לגשת אליהם דרך PackageInfo.signingInfo.

• אם אתם מאשרים את האפליקציה ל-Android באמצעות מסוף Google Cloud, שימו לב שממשק המשתמש מצפה שטביעת האצבע מסוג SHA-1 תהיה מחרוזת שמופרדת בנקודתיים, למשל 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33. עם זאת, הכלי gcloud וה-API של מפתחות ה-API מצפים למחרוזת הקסדצימלית ללא מפרידים.

טיפים לאפליקציות ל-iOS:

• לפני שמשלבים את אפליקציית iOS עם שירותי Google Maps Platform, צריך לוודא שמזהה החבילה בפורמט הנכון.

• בדרך כלל, כשמאשרים את אפליקציית iOS, צריך תמיד להעביר את מזהה החבילה של החבילה הראשית בכותרת X-Ios-Bundle-Identifier.

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

אירוח אפליקציות מבוססות-דפדפן בשרת

סביבות עבודה כמו Apache Cordova מאפשרות ליצור בקלות אפליקציות היברידיות לפלטפורמות מרובות שפועלות בתוך WebView. עם זאת, לא מובטח שהגבלות על אתרים של מפתחות API יפעלו בצורה תקינה, אלא אם אפליקציית האינטרנט נטענת באמצעות HTTP או HTTPS מאתר שבשליטתכם ושהרשיתם.

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

לחלופין, באפליקציות לנייד, כדאי להשתמש בערכות ה-SDK המקוריות של Google Maps Platform ל-Android ול-iOS, במקום להשתמש ב-SDK מבוסס-אינטרנט.

שימוש ב-App Check כדי לאבטח את מפתח ה-API

בחלק מממשקי ה-API וה-SDK של מפות Google אפשר לשלב את בדיקת האפליקציה ב-Firebase. התכונה App Check מספקת הגנה על קריאות מהאפליקציה לפלטפורמה של מפות Google, על ידי חסימת תנועה שמגיעה ממקורות שאינם אפליקציות לגיטימיות. כדי לעשות את זה, הוא בודק אם יש טוקן מספק אימות. שילוב האפליקציות עם App Check עוזר להגן מפני בקשות זדוניות, כדי שלא תחויבו על קריאות לא מורשות ל-API.

הוראות לשילוב של App Check:

• ‫Places SDK ל-iOS
• Places SDK ל-Android
• Maps JavaScript API
• מחלקה Place, ‏Maps JavaScript API

טיפול בשימוש לא מורשה במפתח API

אם זיהיתם שימוש לא מורשה במפתח ה-API שלכם, בצעו את הפעולות הבאות כדי לטפל בבעיה:

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

   • הגבלת מפתחות ה-API
   • מעבר למספר מפתחות API
   • שימוש במפתחות API נפרדים לכל אפליקציה

2. אם אתם משתמשים ב-Places SDK או ב-Maps JavaScript API, אתם יכולים גם להשתמש ב-App Check כדי לאבטח את מפתח ה-API.

3. רק אם התנאי הבא מתקיים, מחליפים או משנים את סבב המפתחות:

   • זיהיתם שימוש לא מורשה במפתחות שאי אפשר להגביל או שהם כבר מוגבלים, ו-App Check לא רלוונטי.

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

   לפני שתמשיכו, קראו את המאמר זהירות כשמחליפים מפתחות API.

4. אם אתם עדיין נתקלים בבעיות או צריכים עזרה, אתם יכולים לפנות לתמיכה.

הגבלות מומלצות על אפליקציות ועל ממשקי API

בקטעים הבאים מפורטות ההגבלות המתאימות על אפליקציות ועל ממשקי API לכל ממשק API, SDK או שירות של Google Maps Platform.

הגבלות מומלצות על ממשקי API

ההנחיות הבאות לגבי הגבלות על ממשקי API חלות על כל השירותים של Google Maps Platform:

• הגבילו את מפתח ה-API רק לממשקי ה-API שבהם אתם משתמשים, למעט המקרים הבאים:

  • אם האפליקציה שלכם משתמשת ב-Places SDK ל-Android או ב-Places SDK ל-iOS, אתם צריכים לתת הרשאה ל-Places API (החדש) או ל-Places API, בהתאם לגרסאות ה-SDK שבהן אתם משתמשים. ¹

  • אם האפליקציה משתמשת ב-Maps JavaScript API, תמיד צריך לאשר אותו במפתח.

  • אם אתם משתמשים גם באחד מהשירותים הבאים של Maps JavaScript API, אתם צריכים לאשר גם את ממשקי ה-API התואמים האלה:

    שירות	הגבלת API
    Directions Service (Legacy)	‫Directions API (הגרסה הקודמת)
    שירות מטריצת מרחקים (דור קודם)	‫Distance Matrix API (הגרסה הקודמת)
    שירות Elevation	Elevation API
    שירות המרת כתובות לקואורדינטות (geocoding)	Geocoding API
    ‫Place class, השלמה אוטומטית למקומות ווידג'ט (חדש) ו- Place Autocomplete Data API	‫Places API (חדש)2
    ספריית המקומות, שירות המקומות ו ווידג'ט ההשלמה האוטומטית למקומות	Places API2

‫¹ לפרטים נוספים, עיינו במסמכי התיעוד של Places SDK ל-Android ושל Places SDK ל-iOS.

² אם אתם לא בטוחים אם צריך לאשר את Places API (חדש) או את Places API (דור קודם), עיינו במסמכי התיעוד של Maps JavaScript API.

מספר דוגמאות:

• אתם משתמשים ב-SDK של מפות ל-Android וב-Places SDK ל-Android, אז אתם כוללים את ה-SDK של מפות ל-Android ואת Places API (החדש) כהגבלות על ממשקי API.

• באתר שלכם נעשה שימוש ב-Maps JavaScript API Elevation Service וב-Maps Static API, אז אתם מוסיפים הגבלות על כל ממשקי ה-API הבאים:

  • Maps JavaScript API
  • Elevation API
  • Maps Static API

הגבלת אפליקציות מומלצות

אתרים

באתרים שמשתמשים בשירותים של Maps JavaScript API, ‏Maps Static API או Street View Static API, או שולחים קריאות לשירותים עדכניים של Google Maps Platform ישירות דרך HTTPS API בארכיטקטורת REST או gRPC, צריך להשתמש בהגבלת האפליקציה Websites:

Directions Service (הגרסה הקודמת) Distance Matrix Service (דור קודם) שירות גובה שירות המרת כתובות לקואורדינטות (geocoding)

Maps JavaScript API1 ספריית מקומות2 Maps Static API3 Street View Static API3

‫¹ באפליקציות לנייד, כדאי להשתמש ב-SDK של מפות ל-Android וב-SDK של מפות ל-iOS.

‫² באפליקציות לנייד, כדאי להשתמש ב-Places SDK ל-Android וב-Places SDK ל-iOS.

‫³ ראו גם הגנה על השימוש ב-Static Web API.

אתרים עם Maps Embed API

השימוש ב-Maps Embed API הוא בחינם, אבל עדיין צריך להגביל את השימוש במפתח ה-API כדי למנוע ניצול לרעה בשירותים אחרים.

שיטה מומלצת: צרו מפתח API נפרד לשימוש ב-Maps Embed API, והגבילו את המפתח הזה ל-Maps Embed API בלבד. ההגבלה הזו מאבטחת את המפתח בצורה מספקת, ומונעת שימוש לא מורשה בו בכל שירות אחר של Google. כדי לקבל שליטה מלאה על המקומות שבהם אפשר להשתמש במפתח Maps Embed API, ‏ Google ממליצה להחיל גם הגבלות על אפליקציות מסוג אתרים.

אם אתם לא יכולים להפריד את השימוש ב-Maps Embed API למפתח API נפרד, אתם יכולים לאבטח את המפתח הקיים באמצעות הגבלת האפליקציה Websites.

אפליקציות ושרתים שמשתמשים בשירותי אינטרנט

לשרתים ולאפליקציות בצד הלקוח מרשתות פנימיות מהימנות של הארגון, שמשתמשות בשירותי אינטרנט יחד עם מפתחות API, משתמשים בהגבלת האפליקציה IP addresses.

אפשר להשתמש במפתח הזה באפליקציות ובשרתים שמשתמשים בממשקי ה-API הבאים:

Address Validation API Aerial View API Air Quality API Directions API (דור קודם)4 Distance Matrix API (דור קודם)4 Elevation API ‫Geocoding API5 Geolocation API6 Map Tiles API

Maps Datasets API Places API (New)7 Places API (דור קודם)6 Roads API ‫Routes API4 Pollen API Solar API Time Zone API8 Weather API

‫⁴ באפליקציות לנייד, כדאי להשתמש ב-Navigation SDK.

⁵ כדי להשתמש בנייד בצורה בטוחה, השתמשו בשרת proxy מאובטח.

⁶ באפליקציות בצד הלקוח, כדאי להשתמש בשירות המיקום הגיאוגרפי המקורי של הפלטפורמה. לדוגמה, W3C Geolocation לדפדפני אינטרנט, LocationManager או ספק מיקום משולב (FLP) ל-Android, או מסגרת Core Location של Apple ל-iOS.

‫⁷ באפליקציות לנייד, כדאי להשתמש ב-Places SDK ל-Android וב-Places SDK ל-iOS.

⁸ כדי להשתמש בצד הלקוח באופן בטוח, צריך להשתמש בשרת proxy מאובטח.

אפליקציות ל-Android

באפליקציות ל-Android, צריך להשתמש בהגבלת האפליקציה Android apps. צריך להשתמש בגרסה הזו באפליקציות שמשתמשות בערכות ה-SDK האלה:

• SDK של מפות ל-Android
• Places SDK ל-Android
• ‫Navigation SDK ל-Android

בנוסף, כדי למנוע בדיקה מקרית של מפתחות API בניהול גרסאות, השתמשו ב-Secrets Gradle Plugin כדי להוסיף סודות מקובץ מקומי במקום לאחסן אותם במניפסט של Android.

אפליקציות ל-iOS

באפליקציות ל-iOS, צריך להשתמש בהגבלת האפליקציה iOS apps. אפשר להשתמש באפליקציות ובשרתים שמשתמשים בערכות ה-SDK האלה:

• SDK של מפות ל-iOS
• ‫Places SDK ל-iOS
• ‫Navigation SDK ל-iOS

קריאה נוספת

• ניהול מפתחות API
• שימוש במפתחות API כדי לגשת לממשקי API
• אופטימיזציה של השימוש ב-Google Maps Platform באמצעות מכסות (סרטון)
• איך יוצרים ומגבילים מפתחות API ל-Google Maps Platform (סרטון)
• הגבלת מפתחות API
• אבטחת מפתחות API כשמשתמשים בממשקי ה-API של Street View ו-Static Maps
• ‫15 שיטות מומלצות לשימוש ב-Google Maps Platform