Rozważania o bezpieczeństwie w dostępie do API

Tworzę rozszerzenie do chrome. Rozszerzenie to odpytuje pewien adres w API. Użytkownik nie musi się w żaden sposób uwierzytelniać.

Na razie mam wydać wersję "do testów". Zastanawiam się nad bezpieczeństwem i możliwością kontroli tego, czy rozszerzenie w wersji testowej w ogóle działa. Obawiam się mianowicie, że rozszerzenie trafi w niepowołane ręce i atakujący sprawdzi sobie, jaki adres jest odpytywany, a następnie napisze automat, który zrobi mi DDoS albo wyciągnie wszystkie dane, albo wykorzysta sobie to API w jeszcze inny sposób, na który nie wpadłam. Chciałabym więc móc np. uniemożliwić działanie wersji testowej, jeśli okaże się, że tak trzeba.

Ponieważ użytkownik się nie loguje i nie mam żadnych danych uwierzytelniających, z których mogłabym skorzystać, pomyślałam, że można by dodać jakiś sekret po stronie rozszerzenia, który był by znany po stronie backendu. Sekret zmieniałby się z każdą wersją. Ale wtedy ten sekret byłby w plikach js, widocznych dla każdego... Zaczęłam więc googlać po słować "how to store API key in frontend" no i oczywista odpowiedź jest by nie przechowywać klucza API po stronie frontendu ;) Powtarza się sugestia, by użyć middle-api, w którym przechowam klucze i przekażę dalej.

Doskonale rozumiem tą ideę, gdy chodzi mi o klucze do zewnętrznych usług, tylko co mi po takim middle-api, jeśli chcę właśnie, by dany klient niekoniecznie mógł otrzymać odpowiedź na swoje zapytanie...?

Wyobraziłam sobie, że można by po stronie api dodać taką metodę, która na podstawie nr wersji rozszerzenia zwróci jakiś token, który będzie się zmieniał w czasie i będzie specyficzny dla danej wersji. A tak naprawdę, to zamiast numeru wersji musiałby być to jakiś losowy ciąg znaków, żeby atakujący nie mógł sobie po prostu podbić wersji w zapytaniu. Czyli i tak mamy sekret po stronie JS, ale służy on tylko temu, żeby otrzymać kolejny token (zmienny w czasie), który daje nam dostęp do głównej metody API.

Tylko po co? Czy nie jest to trochę sztuka dla sztuki? -_- Atakujący i tak może sobie podejrzeć to działanie w JS i odwzorować dokładnie to samo. No fakt, że będzie mu trochę trudniej, niż gdy dostanie sekret na twarz...

Pomóżcie rozważyć za i przeciw. Jak wy to robicie? Jakie inne formy zabezpieczenia powinnam rozważyć?

Do zabezpieczania przed DDoS to chyba są gotowce: https://www.cloudflare.com/ddos/

Co do zabezpieczania danych to masz raczej sprzeczne założenia. Z jednej strony usługa jest publicznie dostępna bez logowania się, a z drugiej ma być ograniczana? Możesz ewentualnie zrobić hybrydę, np powolna i ograniczona wersja dla niezalogowanych oraz szybka i nieograniczona dla zalogowanych.

Jak chcesz uniknać zlośliwych odswieżaczy to ustaw jakis limit zapytań na ip. Ew możesz próbować coś z cookie (np jakies uuid dla usera), ale tym zablokujesz samych amatorów. Jeżeli chcesz trzymac jakies poufne dane to bez kont się nie obejdzie.

Z jednej strony usługa jest publicznie dostępna bez logowania się, a z drugiej ma być ograniczana?

To, że chcę pozwolić użytkownikowi skorzystać z jakichś funkcjonalności, nie oznacza, że zgadzam się na to by konkurencja skorzystała sobie z mojego api w swoim produkcie...

Możesz ewentualnie zrobić hybrydę, np powolna i ograniczona wersja dla niezalogowanych oraz szybka i nieograniczona dla zalogowanych.

To jak aplikacja wygląda (tzn. jakie ma funkcjonalności i dla kogo) nie zależy ode mnie. Użytkownicy nie muszą się uwierzytelniać.

aurel napisał(a):

Z jednej strony usługa jest publicznie dostępna bez logowania się, a z drugiej ma być ograniczana?

To, że chcę pozwolić użytkownikowi skorzystać z jakichś funkcjonalności, nie oznacza, że zgadzam się na to by konkurencja skorzystała sobie z mojego api w swoim produkcie...

Czyli zostaje banowanie po IP jak jest za dużo zapytań lub captcha. Czyli tak jak to robi Google żeby Bing nie wyświetlał wyników z Google jako swoje