Wyświetlanie wersji pakietu SDK zawierających potencjalne problemy związane ze zgodnością z zasadami lub luki w zabezpieczeniach

Ta strona zawiera materiały pomocy dla dostawców SDK korzystających z Google Play SDK Console.

Jeśli jesteś deweloperem aplikacji i szukasz materiałów dotyczących Konsoli Google Play, użyj paska wyszukiwania lub wróć na stronę główną.

Dzięki SDK Console możesz być na bieżąco z potencjalnymi naruszeniami zasad i lukami w zabezpieczeniach, które mogą mieć wpływ na wersje Twojego pakietu SDK. Jest to ważne dla zapewnienia bezpieczeństwa w Google Play i uniknięcia potencjalnych negatywnych konsekwencji dla Twoich pakietów. Może to obejmować usunięcie plakietki informującej o rejestracji lub ograniczenie dostępu do funkcji w Google Play SDK Console.

Wersje pakietu SDK z potencjalnymi problemami związanymi z naruszeniem zasad

Wersje pakietu SDK, przez które aplikacje z nich korzystające są niezgodne z naszymi wymaganiami dotyczącymi pakietów SDK lub innymi zasadami programu dla deweloperów w Google Play, będą oznaczone w SDK Console. Opublikowane w Google Play nowe wersje aplikacji, które korzystają z tych wersji, zostaną odrzucone, a deweloperzy zostaną poproszeni o znalezienie zgodnych wersji przed ponownym przesłaniem aplikacji.

Zrzut ekranu poniżej pokazuje wersję pakietu SDK z zaznaczonym naruszeniem zasad:

Zrzut ekranu poniżej pokazuje rozwinięte informacje o wersji pakietu SDK ze szczegółami zgłoszonego problemu:

Zgodnie z Warunkami korzystania z SDK Console, jeśli w pakiecie SDK wykryjemy potencjalne naruszenie zasad, powiadomimy Cię o tym oraz poinformujemy, jak rozwiązać ten problem i przesłać nową wersję pakietu SDK do sprawdzenia. Po zakończeniu procesu egzekwowania zasad w dotychczasowych aplikacjach SDK Console oznaczy problematyczne wersje pakietu SDK jako niezgodne z zasadami. Nowe wersje aplikacji, które je zawierają, nie będą mogły zostać opublikowane, dopóki deweloperzy nie przejdą na zgodną wersję.

Możliwe konsekwencje wielokrotnego naruszenia zasad związanych z pakietem SDK

Google Play dokłada wszelkich starań, aby zapewnić bezpieczny i godny zaufania ekosystem zarówno deweloperom, jak i użytkownikom. W ramach tego zobowiązania stosujemy zaawansowane metody ograniczania powtarzających się naruszeń zasad Google Play spowodowane przez pakiety SDK:

W zależności od powagi i częstotliwości naruszeń konsekwencje mogą obejmować między innymi:

  • Usunięcie plakietki informującej o rejestracji – powtarzające się naruszenia zasad o takiej samej lub większej wadze mogą skutkować usunięciem plakietki informującej o rejestracji, która jest widoczna na platformie Google Play SDK Index. Plakietka wskazuje, że pakiet SDK jest zarejestrowany w Google Play SDK Console, a dostawca tego pakietu zaakceptował Warunki korzystania z usługi Google Play SDK Console. Obejmują one zobowiązanie, że pakiety SDK nie będą powodowały naruszania zasad Google Play przez aplikacje.
  • Ograniczony dostęp do funkcji w Google Play SDK Console: w przypadku pakietów SDK, które powodowały powtarzające się naruszenia zasad (o takiej samej lub większej wadze) przez deweloperów aplikacji, zastrzegamy sobie prawo do usunięcia dostępu do kluczowych funkcji w SDK Console.

Uwaga: dostawcy pakietów SDK nadal mogą zadawać pytania na temat wydanych decyzji. Więcej informacji znajdziesz w tym artykule w Centrum pomocy na temat bezpiecznego korzystania z pakietów SDK oraz w zasadach programu dla deweloperów w Google Play.

Wersje pakietu SDK z potencjalnymi lukami w zabezpieczeniach

Luka w zabezpieczeniach to podatność lub błąd w kodzie, który może zostać wykorzystany przez atakującego. SDK Console informuje o potencjalnych lukach w zabezpieczeniach, które mogą mieć wpływ na wersje Twojego pakietu SDK. Poniżej znajdziesz informacje o lukach w zabezpieczeniach, które mogą wpływać na Twój pakiet SDK, oraz o sposobach ich usuwania.

Potencjalnie niebezpieczne szyfrowanie kryptograficzne

Rozwiązywanie problemów z pakietami SDK, które zawierają niebezpieczne wzorce szyfrowania

Twój pakiet SDK zawiera niebezpieczne wzorce szyfrowania. Oznacza to, że tekst szyfrowany jest generowany ze statycznie obliczonym kluczem tajnym, ciągiem zaburzającym lub wektorem inicjującym (IV).

Jeśli aplikacja używa Twojego pakietu SDK, w Konsoli Play wyświetli się odpowiedni alert. Aby zapobiec otrzymywaniu alertów dotyczących aplikacji, które używają Twojego pakietu SDK, musisz usunąć lukę w zabezpieczeniach tego pakietu.

Aby rozwiązać ten problem w pakiecie SDK, wykonaj opisane niżej czynności. Informacje o niebezpiecznych lokalizacjach kodu szyfrowania znajdziesz w powiadomieniu z SDK Console dotyczącym pakietu SDK.

Dodatkowe informacje

Sprawdź statycznie obliczone klucze, wektory inicjujące lub ciągi zaburzające w operacjach szyfrowania i upewnij się, że wartości te są tworzone w bezpieczny sposób. Na przykład ten kod używa statycznie obliczonego klucza tajnego i statycznie obliczonego wektora inicjującego:

// Alert konsoli odnosi się do tej metody
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {
    Cipher cipher = Cipher.getInstance(“AES/GCM/NoPadding”);
    SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), “AES”);
    GCMParameterSpec paramSpec = new GCMParameterSpec(256, iv.getBytes());
    cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
    return cipher.doFinal(plainText);
  }

  // Znajdują się tutaj niebezpieczny klucz i wektor inicjujący, które należy zmienić
  byte[] cipherText = encryptionUtil(“abcdef...”, “010203040506”, plainText);

Statycznie obliczone wartości
Statycznie obliczona wartość to taka, która jest identyczna przy każdym wykonaniu funkcji. Statycznie obliczone wartości można wyodrębnić z pakietu SDK i wykorzystać do ataku na zaszyfrowane dane aplikacji. Nawet gdy przy użyciu złożonych metod zmienisz klucze, wektory inicjujące i ciągi zaburzające, pozostaną one niebezpieczne, jeśli zmiany te będą takie same przy każdym wykonaniu programu.

Sprawdzone metody w przypadku Androida
Zalecamy używanie usługi Jetpack Security do symetrycznej kryptografii. Jeśli Twój pakiet SDK szyfruje klucze interfejsu API, informacje umożliwiające identyfikację lub inne dane wrażliwe, możesz użyć elementu EncryptedSharedPreferences, aby w bezpieczny sposób przechowywać takie dane i nie martwić się o implementację kluczy tajnych, wektorów inicjujących i ciągów zaburzających. Więcej sprawdzonych metod i przykładów znajdziesz na tej stronie. Aby bezpiecznie przesyłać dane do innych systemów, deweloperzy powinni używać protokołu TLS/SSL.

Usługa Jetpack Security obsługuje symetryczne, uwierzytelnione szyfrowanie przy użyciu stworzonego przez Google projektu open source o nazwie Tink. W zaawansowanych zastosowaniach dotyczących operacji niższego poziomu zalecamy bezpośrednie używanie biblioteki Tink.

Jeśli wymienione powyżej sprawdzone metody w przypadku Androida nie sprawdzają się w Twojej sytuacji i musisz w sposób jawny zarządzać kluczami, wektorami inicjującymi i ciągami zaburzającymi, zalecamy zastosowanie tych standardów:

  • Klucze tajne: symetrycznie klucze tajne muszą być nieprzewidywalne i tajne. Na potrzeby szyfrowania danych lokalnych deweloperzy powinni tworzyć klucze tajne przy użyciu bezpiecznej losowości (lub z danych wygenerowanych przez użytkownika, jeśli używany jest element PBEKeySpecs) i przechowywać te klucze za pomocą systemu AndroidKeystore.
  • Wektory inicjujące: muszą być unikatowe i nieprzewidywalne w wielu wiadomościach, ale nie muszą być tajne. Deweloperzy powinni tworzyć wektory inicjujące przy użyciu kryptograficznie bezpiecznej losowości oraz przechowywać lub przesyłać je razem z powiązanym tekstem szyfrowanym.
  • Ciągi zaburzające: muszą być unikatowe i nieprzewidywalne w wielu haszach, ale nie muszą być tajne. Deweloperzy powinni tworzyć te ciągi przy użyciu kryptograficznie bezpiecznej losowości oraz przechowywać lub przesyłać je razem z powiązanymi haszami.
Wykorzystanie potencjalnie niebezpiecznego trybu szyfrowania

Rozwiązywanie problemów z pakietami SDK, które używają mniej bezpiecznych trybów szyfrowania

Twój pakiet SDK zawiera szyfrowanie z wykorzystaniem mniej bezpiecznego trybu AES/ECB. Szyfrowanie treści za pomocą takich trybów może prowadzić do generowania niewystarczająco zaszyfrowanych tekstów i potencjalnie narażać dane użytkowników.

Jeśli aplikacja korzysta z Twojego pakietu SDK, w Konsoli Play wyświetli się odpowiedni alert. Aby zapobiec otrzymywaniu alertów dotyczących aplikacji, które używają Twojego pakietu SDK, musisz usunąć lukę w zabezpieczeniach tego pakietu.

Aby rozwiązać ten problem w pakiecie SDK, wykonaj opisane niżej czynności. Lokalizacje kodu z mniej bezpiecznymi trybami szyfrowania znajdziesz w powiadomieniu SDK Console dotyczącym Twojego pakietu SDK.

Dodatkowe informacje

Sprawdź, gdzie w pakiecie SDK powstaje instancja mechanizmu szyfrowania. Te tryby konfiguracji sugerują korzystanie z potencjalnie niebezpiecznych metod AES/ECB:

"AES"

"AES/ECB/NoPadding"

"AES/ECB/PKCS5Padding"

"AES/ECB/ISO10126Padding"

Na przykład ten kod domyślnie używa trybu AES/ECB, ponieważ występuje w nim „AES”:

// Alert konsoli odnosi się do tej metody
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {
    Cipher cipher = Cipher.getInstance(“AES”); 
// Domyślnie używany jest tryb AES/ECB
    SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), “AES”);
    cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
    cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
    return cipher.doFinal(plainText);

}

Google zaleca deweloperom korzystanie z trybu “AES/GCM/NoPadding” zamiast powyższego potencjalnie niebezpiecznego trybu.

Przemierzanie ścieżki ZIP

Rozwiązywanie problemów z pakietami SDK zawierającymi kod podatny na przemierzanie ścieżki ZIP

Kod w pakiecie SDK zawiera niebezpieczne wzorce rozpakowywania, które mogą prowadzić do ataku wykorzystującego przemierzanie ścieżki ZIP.

Jeśli aplikacja używa Twojego pakietu SDK, w Konsoli Play wyświetli się odpowiedni alert. Aby zapobiec otrzymywaniu alertów dotyczących aplikacji, które używają Twojego pakietu SDK, musisz usunąć lukę w zabezpieczeniach tego pakietu.

Aby rozwiązać ten problem w pakiecie SDK, wykonaj dokładnie opisane niżej czynności. Informacje o niebezpiecznych lokalizacjach wzorców rozpakowywania znajdziesz w powiadomieniu z SDK Console dotyczącym pakietu SDK.

Dodatkowe informacje

Pliki ZIP mogą zawierać element (plik lub katalog), w którego nazwie znajdują się znaki przemierzania ścieżki („../”). Jeśli deweloperzy rozpakują takie elementy pliku ZIP bez sprawdzenia poprawności ich nazwy, może to spowodować atak z wykorzystaniem przemierzania ścieżki i doprowadzić do zapisania ich w przypadkowych katalogach lub nawet zastąpienia plików w prywatnych folderach aplikacji.

Zalecamy naprawienie tego problemu w pakiecie SDK. W tym celu sprawdź, czy ścieżki kanoniczne do rozpakowanych plików prowadzą do odpowiedniego katalogu. Przed skorzystaniem z obiektu File utworzonego przy użyciu wartości zwrotnej metody getName() klasy ZipEntry należy zawsze sprawdzić, czy wartość zwrotna metody File.GetCanonicalPath() należy do ścieżki prawidłowego katalogu. Przykład:

InputStream is = new InputStream(untrustedFileName);
ZipInputStream zis = new ZipInputStream(new BufferedInputStream(is));
while((ZipEntry ze = zis.getNextEntry()) != null) {
  File f = new File(DIR, ze.getName());
  String canonicalPath = f.getCanonicalPath();
  if (!canonicalPath.startsWith(DIR)) {
   
// Wyjątek zabezpieczeń
  }
 
// Kończenie rozpakowywania…
}

Intencja ogólna PendingIntent

Rozwiązywanie problemów z pakietami SDK, które zawierają lukę w zabezpieczeniach typu intencja ogólna PendingIntent

W Twoim pakiecie SDK występuje problem dotyczący intencji ogólnej PendingIntent, który może stanowić zagrożenie dla bezpieczeństwa i umożliwiać np. ataki typu DoS, kradzież danych osobistych oraz eskalację uprawnień.

Jeśli aplikacja korzysta z Twojego pakietu SDK, w Konsoli Play wyświetli się odpowiedni alert. Aby zapobiec otrzymywaniu alertów dotyczących aplikacji, które używają Twojego pakietu SDK, musisz usunąć lukę w zabezpieczeniach tego pakietu.

Aby rozwiązać ten problem w pakiecie SDK, wykonaj dokładnie opisane niżej czynności. Lokalizacje kodu związane z zastosowaniem intencji ogólnej PendingIntent znajdziesz w powiadomieniu w SDK Console dotyczącym Twojego pakietu SDK.

Dodatkowe informacje

Aplikacje na Androida wysyłają wiadomości między komponentami za pomocą intencji. Intencje mogą określać komponent docelowy (intencja bezpośrednia) lub podać ogólne działanie i pozwolić systemowi operacyjnemu przekazać intencję do dowolnego komponentu na urządzeniu, które rejestruje filtr intencji pasujący do tego działania (intencja ogólna).

PendingIntent to intencja, która została przekazana do innej aplikacji i zostanie dostarczona w przyszłości. Utworzenie intencji ogólnej w intencji PendingIntent stanowi lukę w zabezpieczeniach, która może umożliwiać ataki typu DoS, kradzież danych osobowych i eskalację uprawnień.

Znajdź w pakiecie SDK miejsce, w którym jest używana intencja PendingIntent. Na przykład ten kod tworzy intencję ogólną w intencji PendingIntent:

// Utworzenie podstawowej intencji ogólnej i umieszczenie jej w intencji PendingIntent

Intent base = new Intent("ACTION_FOO");

base.setPackage("some_package");

PendingIntent pi = PendingIntent.getService(this, 0, base, 0);

Aby naprawić lukę w zabezpieczeniach, należy skorzystać z jednego (a najlepiej wszystkich) z poniższych sposobów zalecanych przez Google:

  • Upewnienie się, że działanie, pakiet oraz pola komponentu podstawowej intencji są ustawione.
  • Upewnienie się, że intencja PendingIntent zostanie dostarczona tylko do zaufanych komponentów.
  • Użycie flagi FLAG_IMMUTABLE (dodanej w SDK 23) do tworzenia intencji PendingIntent. Uniemożliwi to aplikacjom, które otrzymują intencje PendingIntent, wypełnianie brakujących właściwości. Jeśli aplikacja działa też na urządzeniach z pakietem SDK 22 lub starszym, deweloperzy powinni skorzystać z jednego z poprzednich rozwiązań i wzmocnić utworzoną intencję PendingIntent w ten sposób:

if (android.os.Build.VERSION.SDK_INT >= 23) {

  // Utworzenie intencji PendingIntent za pomocą flagi FLAG_IMMUTABLE

} else {

  // Dotychczasowy kod tworzący intencję PendingIntent

}

Wewnętrzna intencja ogólna

Rozwiązywanie problemów z pakietami SDK, które zawierają lukę w zabezpieczeniach typu wewnętrzna intencja ogólna

W Twoim pakiecie SDK występuje problem związany z wewnętrzną intencją ogólną. Intencje ogólne, używane, aby dotrzeć do wewnętrznego komponentu, pomagają osobom przeprowadzającym atak przechwycić wiadomość, a następnie porzucić ją, odczytać jej zawartość lub nawet tę zawartość podmienić.

Jeśli aplikacja korzysta z Twojego pakietu SDK zawierającego lukę w zabezpieczeniach, w Konsoli Play wyświetli się odpowiedni alert. Aby zapobiec otrzymywaniu alertów dotyczących aplikacji, które używają Twojego pakietu SDK, musisz usunąć lukę w zabezpieczeniach tego pakietu.

Aby rozwiązać ten problem w pakiecie SDK, wykonaj dokładnie opisane niżej czynności. Miejsca wystąpienia intencji ogólnej w Twoim pakiecie SDK znajdziesz w powiadomieniu z SDK Console.

Dodatkowe informacje

Znajdź w aplikacji miejsce, w którym jest używana intencja ogólna. Na przykład ten kod korzysta z intencji ogólnej, aby dotrzeć do wewnętrznego komponentu:

//Ta aplikacja ma komponent rejestrujący intencję MY_CUSTOM_ACTION, która jest

//rejestrowana tylko przez tę aplikację, co wskazuje, że deweloper chce, aby ta intencja

//została bezpiecznie dostarczona do komponentu wewnętrznego.

Intent intent = new Intent("MY_CUSTOM_ACTION");

//Tutaj do elementu „intent” dodano potencjalnie wrażliwe treści

intent.putExtra("message", sensitive_content);

startActivity(intent);

Google zaleca programistom korzystanie z intencji bezpośrednich, aby można było dotrzeć do komponentów wewnętrznych na jeden z tych sposobów:

Znana biblioteka z lukami w zabezpieczeniach (JS)

Rozwiązywanie problemów z pakietami SDK, które zawierają biblioteki JavaScript z lukami w zabezpieczeniach

Twój pakiet SDK zawiera co najmniej 1 bibliotekę JavaScriptu, w której występują znane problemy z bezpieczeństwem (np. luki w zabezpieczeniach i elementy podatne na atak opisane w dokumentach CVE). Takie biblioteki mogą narażać użytkowników aplikacji na niebezpieczeństwo.

Jeśli aplikacja używa Twojego pakietu SDK zawierającego luki w zabezpieczeniach, w Konsoli Play wyświetli się odpowiedni alert. Aby zapobiec otrzymywaniu alertów dotyczących aplikacji, które używają Twojego pakietu SDK, musisz rozwiązać problem dotyczący tego pakietu.

Aby rozwiązać ten problem w pakiecie SDK, wykonaj dokładnie opisane niżej czynności. Listę niebezpiecznych bibliotek i ich wersji używanych w pakiecie SDK znajdziesz w odpowiednim powiadomieniu w SDK Console.

Dodatkowe informacje

Aby rozwiązać problem, możesz wykonać jedną z opisanych niżej czynności w odniesieniu do każdej niebezpiecznej biblioteki:

  1. Użyj aktualnej wersji biblioteki. Jeśli pakiet SDK zależy bezpośrednio od niebezpiecznej wersji biblioteki, a problem z zabezpieczeniami został rozwiązany w najnowszej wersji biblioteki, przebuduj pakiet SDK, używając najnowszej wersji.
  2. Skontaktuj się z deweloperem biblioteki. Biblioteka może być nadal aktywnie rozwijana, ale problem z zabezpieczeniami nie został jeszcze rozwiązany. Pakiet SDK może też być pośrednio zależny od niebezpiecznej biblioteki – może na przykład zawierać bezpieczną bibliotekę, która jest jednak zależna od biblioteki mającej luki. W takiej sytuacji zalecamy skontaktowanie się z deweloperem biblioteki.
  3. Znajdź bibliotekę alternatywną. Jeśli niebezpieczna biblioteka zawierająca co najmniej jedną lukę w zabezpieczeniach nie jest już rozwijana, znajdź i wykorzystaj inną, bezpieczną bibliotekę.
Potencjalnie niebezpieczne wykorzystanie protokołu OAuth w WebView

Rozwiązywanie problemów z pakietami SDK, które korzystają z komponentów WebView do uwierzytelniania

Twój pakiet SDK używa do uwierzytelniania komponentu WebView, co nie jest zalecane. Używanie komponentów WebView do obsługi żądań OAuth 2.0 negatywnie wpływa na bezpieczeństwo i łatwość obsługi aplikacji korzystających z Twojego pakietu SDK. Aby rozwiązać ten problem w pakiecie SDK, wykonaj opisane niżej czynności.

Jeśli aplikacja używa Twojego pakietu SDK, w Konsoli Play wyświetli się odpowiedni alert. Aby zapobiec otrzymywaniu alertów dotyczących aplikacji, które używają Twojego pakietu SDK, musisz usunąć lukę w zabezpieczeniach tego pakietu.

Lokalizacje kodu żądań OAuth 2.0, które korzystają z komponentów WebView w pakiecie SDK, znajdziesz w powiadomieniu w SDK Console dotyczącym Twojego pakietu SDK.

Dodatkowe informacje

Od czasu wprowadzenia kart niestandardowych Chrome Google zaleca deweloperom rezygnację z uwierzytelniania za pomocą komponentów WebView. Korzystanie z protokołu OAuth do uwierzytelniania w komponencie WebView może spowodować, że aplikacje używające Twojego pakietu SDK będą podatne na zagrożenia, i utrudnić ich obsługę, powodując przerywanie sesji logowania jednokrotnego użytkowników. Karty niestandardowe Chrome eliminują te problemy.

  1. Znajdź w pakiecie SDK miejsce, w którym jest wysyłane żądanie OAuth 2.0 za pomocą komponentu WebView.
  2. Google zaleca programistom zastąpienie tego komponentu WebView kartą niestandardową Chrome. Wykonaj czynności opisane w podręczniku implementacji kart niestandardowych Chrome, aby dodać taką kartę do pakietu SDK.
  3. Zacznij używać dodanej karty niestandardowej Chrome do obsługi żądań OAuth 2.0.
Ujawnione klucze GCP

Rozwiązywanie problemów z pakietami SDK, które ujawniają klucze interfejsu API GCP

Twój pakiet SDK zawiera ujawnione klucze interfejsu API Google Cloud Platform (GCP). Jeśli umieścisz w swoim pakiecie SDK klucze interfejsu API GCP, staną się one publicznie dostępne. Ujawnienie kluczy API może skutkować nieoczekiwanymi opłatami i zmianami limitu na koncie GCP pakietu SDK.

Jeśli aplikacja używa Twojego pakietu SDK zawierającego luki w zabezpieczeniach, w Konsoli Play wyświetli się odpowiedni alert. Aby zapobiec otrzymywaniu alertów dotyczących aplikacji, które używają Twojego pakietu SDK, musisz usunąć lukę w zabezpieczeniach tego pakietu.

Aby rozwiązać ten problem w pakiecie SDK, wykonaj dokładnie opisane niżej czynności. Lokalizacje ujawnionych kluczy interfejsu API GCP w Twoim pakiecie SDK znajdziesz w odpowiednim powiadomieniu SDK Console.

Dodatkowe informacje

Aby naprawić ten problem w pakiecie SDK, użyj jednego z tych rozwiązań:

  1. Jeśli to możliwe, używaj kont usługi GCP zamiast kluczy interfejsu API GCP do uwierzytelniania aplikacji. Konto usługi GCP jest kontem Google powiązanym z projektem GCP. Więcej informacji o tworzeniu i korzystaniu z kont usługi znajdziesz tutaj.
  2. Dodaj ograniczenia do klucza interfejsu API, aby mogły z niego korzystać tylko Twoje pakiety SDK lub aplikacje. Więcej informacji na temat dodawania ograniczeń do kluczy API znajdziesz tutaj. Uwaga: jeśli do klucza interfejsu API masz już dodane ograniczenia, możesz zignorować to ostrzeżenie.
Zapoznaj się ze sprawdzonymi metodami GCP dotyczącymi bezpiecznego korzystania z kluczy interfejsu API.

Czy to było pomocne?

Jak możemy ją poprawić?

Potrzebujesz dodatkowej pomocy?

Wykonaj te czynności:

Szukaj
Wyczyść wyszukiwanie
Zamknij wyszukiwanie
Menu główne
1349221408153593876
true
Wyszukaj w Centrum pomocy
true
true
true
true
true
92637
false
false
false