zabezpieczanie klucza API

Witam,
czy istnieje możliwość zabezpieczenia klucza API w zapytaniu, aby nie był on widoczny w debugerze? Chodzi o to, że mam funkcję fetch, w której mam adres URL do openweathermap, w którym znajduje się klucz API. Cały ten kod można podejrzeć w konsoli i w ten sposób może wyciec klucz API, a tego nie chce. Czy ma ktoś pomysł jak temu zaradzić? Czy będzie trzeba zrobić to w PHP?

To co masz w JS i co wykonuje się po stronie przeglądarki można zawsze podejrzeć. Możesz dopisać jakaś funkcję kodująca, no ale i tak ktoś kogo ten klucz zainteresuje to znajdzie tą funkcję.

Jeśli zapytanie do OWM jest wykonywane przez kod JS w przeglądarce, to jak zauważyłeś, można go podejrzeć. Żadne szyfrowanie czy cudowanie nie pomoże, bo ostatecznie cwany użytkownik wejdzie w zakładkę Network i będzie go widział. Najczęstsze rozwiązanie to odpytywanie swojego backendu (np. tak jak mówisz w PHP), a backend odpytuje zewnętrzny serwis, odpowiedź przekazując na frontend. Wtedy klucz zostaje na serwerze.

@kelog: a w jaki sposób zabezpieczysz się przed tym, żeby ktoś inny nie zaczął z boku bombardować tego backendu zapytaniami? Klucz zasłonisz w ten sposób, ale jeśli np. masz naliczane opłaty za każde skorzystanie z klucza, to i tak możesz się narazić na nieplanowane wydatki.

A to już inne pytanie :) Fakt, należało by zastosować coś, co uniemożliwi nadużywanie dostępu do API. Limit odpytań na minutę/godzinę, limit per użytkownik, jakiś backpressure może.

Niektóre API, zwłaszcza te płatne albo bardzo płatne mają opcję ograniczenia zapytań do konkretnej domeny - jak ktoś nie uderza z Twojej domeny to ten klucz będzie dla niego bezużyteczny. Więc możesz spróbować poszukać takiej opcji. W Google Maps mają coś takiego (https://webmasters.stackexchange.com/a/95919) wiec w OWM może ma podobnie.

Gouda105 napisał(a):

czy istnieje możliwość zabezpieczenia klucza API w zapytaniu, aby nie był on widoczny w debugerze?

Tak, istnieje, jest tylko jedna skuteczna metoda => nie ujawniać niepublicznych danych. Jakiś publiczny klucz w ścieżce ujdzie, ale jakiś ClientSecret... nope my friend. Wiele stron, które ma jakieś usługi i sekretne klucze API zawsze krzyczy, żeby ich kluczy nie ujawniać. Radzę stosować się do tych zaleceń :)

@TomekCph: ale też wiele stron nie krzyczy i nie oferuje żadnych zabezpieczeń lub nawet w przykładach zaleca korzystanie na froncie, zresztą, jakbyś przeczytał cały wątek to byś nie popełnił takiego postu.

Jakieś chyba 5 lat temu próbowałem automatycznie zgrać listę stacji z SDR.hu (już to nie istnieje), długo myślałem, dlaczego lista odbiorników w formacie JSON nie odpowiada temu, co wyświetla się na stronie. Okazało się, że odpowiedzi JSON to, co było otwartym tekstem i robiło się czytelne po sformatowaniu tego tekstu, to były tylko śmieci (co odświeżenie, wartości parametrów były inne, co już sugerowało, że coś jest nie tak i że to nie jest użyteczna treść), natomiast prawdziwa treść była zakodowana w spacjach, tabulatorach i enterach. Po dłuższym czasie udało się odnaleźć funkcję, przez którą był przepuszczany ten tekst i na wyjściu dostawałem już tą prawdziwą treść JSON. Nie próbowałem analizować sposobu kodowania tekstu w niewidocznych znakach, bo nie było potrzeby, ale długo nie wpadłem na to, że właśnie w nich może być ukryta wartościowa treść.

Tak, jak przedmówcy napisali, dostęp do danych przetwarzanych po stronie klienta można utrudnić, ale nie można uniemożliwić. Jednak, jak się uprzesz, to może spróbujesz przemycić klucz w spacjach i tabach, dodając do tego jakieś śmieci.

Chyba jedynym sposobem jest PHP lub innej technologii wykonywania kodu po stronie serwera i użycie jakiegoś pośrednika, gdzie pośrednik wczyta mapę pogody, czy co tam chcesz, do siebie korzystając z klucza, a potem odda tą treść do klienta.

mr_jaro napisał(a):

@TomekCph: ale też wiele stron nie krzyczy i nie oferuje żadnych zabezpieczeń lub nawet w przykładach zaleca korzystanie na froncie, zresztą, jakbyś przeczytał cały wątek to byś nie popełnił takiego postu.

No jakieś słabe strony pewnie nie. Ja takich nie spotkałem jeszcze, poza tym, no na logikę, jak ktoś zalecać stosowanie kluczy na froncie, które z zasady są niejawne? Nie kupuję takiego tłumaczenia :) Ogólna zasada - na froncie w JS nic nie jest bezpieczne.

@TomekCph: np wczytywanie map, maptiler najlepszy obecnie odpowiednik google mapsów do wstawiania na stronę, w jaki sposób chcesz wyświetlić dynamiczną mapę na stronie nie podając publicznie klucza? W Dokumentacji jest podane by dodawać listę akceptowanych domen i to się robi ale nie zabezpieczysz się przed tym całkowicie np gdy ktoś sobie na localu postawi taką domenę :)

mr_jaro napisał(a):

@TomekCph: np wczytywanie map, maptiler najlepszy obecnie odpowiednik google mapsów do wstawiania na stronę, w jaki sposób chcesz wyświetlić dynamiczną mapę na stronie nie podając publicznie klucza? W Dokumentacji jest podane by dodawać listę akceptowanych domen i to się robi ale nie zabezpieczysz się przed tym całkowicie np gdy ktoś sobie na localu postawi taką domenę :)

No bo to klucz publiczny i musisz dodać akceptowaną domenę, aby nikt inny jej nie użył (patrz dokumentacja), i w takim przypadku jest to wystarczające zabezpieczenie - nie, na lokalu nikt sobie niczego nie postawi ;)

To chyba zły przykład ;) Chodzi o sekretne klucze, takie, których nie chcemy ujawniać, no takich to ja wolę nie ujawniać.

@TomekCph: Taki sam klucz jak każdy inny z dostępem do api