Jak zabezpieczyć server http przed spamerskimi requestami?

Cześć, jak zabezpieczacie swoje publiczne endpointy w NEXT JS?
Da sie zrobić tak, aby możliwe było uderzenie do nich jedynie z tego samego frontu? Czyli żeby nikt z żadnych postmanów nie mógł spamować?

Używacie dodatkowo jakiejś ReCAPTCHy albo czegoś podobnego? Podobno są problemy z rodo z nią.

nie da się

Moze Ci chodzi o JWT? Wtedy będziesz musiał mieć tokena

@ehhhhh: @Pixello Większość endpointów zabezpieczam JWT ale /register z wiadomych powodów nie. A wspomniana captcha albo rate limiter ?

Auth0

A jak niby miałbyś to rozróżnić?

To jest po prostu request http, przeglądarka wysyła taki sam jak postman. Nawet gdyby przeglądarka wysyłała jakieś specjalne znaczniki, to nadal bot lub inny client mógłby wysłać takie same. Żeby to zrobić, przeglądarki musiałyby mieć specjalne klucze prywatne, i się autentykować że są jednymi z dopuszczalnych klientów, ale to nadal by nie rozwiązało Twojego problemu, bo z takiej przeglądarki nadal możesz strzelić tysiącem niechcianych żądań.

Także w taki sposób się tego nie da osiągnąć.

cerrato napisał(a):

Jedyne co chyba realnie możesz wprowadzić to jakieś limity requestów z danego IP. Jeśli ktoś będzie chciał spamersko walić z jakiegoś serwera to po kilku/nastu/dziesięciu próbach blokujesz. Albo captcha - to dość ciężko (jeszcze póki co) obejść botami.

W tym przypadku to pewnie nie ma wiekszego znaczenia, ale co do zasady lepiej throttlowac uzytkownikow a nie IP bo mozesz w ten sposob np. cala uczelnie albo biurowiec wyciac :)

stivens napisał(a):

W tym przypadku to pewnie nie ma wiekszego znaczenia, ale co do zasady lepiej throttlowac uzytkownikow a nie IP bo mozesz w ten sposob np. cala uczelnie albo biurowiec wyciac :)

Userów - owszem, ma to sens, ale zauważ, co napisał parę postów wcześniej autor wątku - Większość endpointów zabezpieczam JWT ale /register z wiadomych powodów nie. Skoro masz problem/obawę że będzie spamowanie/atak botów na endpoint od rejestracji, to nie da się przecież blokować usera, bo on jeszcze nie istnieje/dopiero powstaje na tym etapie.

Pytanie do @Bambo - czy masz realne podstawy, żeby się tego obawiać, coś się dzieje/działo albo z innego powodu jesteś przekonany, że coś będzie się działo, czy to takie dmuchanie na zimne i zabezpieczanie przed czymś, co może się nigdy nie przytrafić?

@cerrato: dmuchanie na zimne :)

Podpiąłem captche 3, ale rodo w związku z tym trochę pokomplikowane. Mam mechanizm do zarządzania cookiesami, ale nie czaję co mam zrobić jak user nie wyrazi zgoody na cookiesy, które instaluje captcha 3. Wyłączyć wszystkie formularze ? ;P

nie wszystkie cookisy podlegają pod rodo, jedną z grup są "niezbedne do działania systemu" i ich nie można wyłączyć przez odnowę zgody na cookisy.

Co do cookies, RODO oraz captcha:

1. jest pewna grupa ciasteczek (lub ogólnie - innych aspektów technicznych), które są niezbędne do działania systemu
2. jak ktoś nie wyrazi zgody na nie, to po prostu nie może korzystać ze strony. Coś na zasadzie rozmowa jest rejestrowana, jak nie wyrażasz zgody to zakończ rozmowę
3. nie wszystkie cookiesy zbierają informację o użytkowniku. Zauważ, że pod RODO podlegają tylko takie dane, które pozwalają na identyfikację usera. Nie wiem, co konkretnie zbiera, gromadzi i przetwarza cpatcha, ale może nie ma tutaj niczego, czego należy się obawiać.

@cerrato: dla precyzji "identyfikacjia usera" też musi być specyficzna np na potrzeby remarketingu, reklam i tak dalej. Jeśli jest to identyfikacji w postaci cookisa sesji która jest niezbędna do działania systemu to nie ma potrzeby prosić o zgodę o użycie takiego cookisa.

https://wideangle.co/blog/is-recaptcha-illegal-under-gdpr

@ehhhhh: @cerrato
Z tego co tu czytam to nie jest tak łatwo i kolorowo jak opisujecie :)

https://www.akamai.com/products/app-and-api-protector

Co prawda rozwiazanie enterpirse, ale dla przykładu duże firmy w ten sposób to rozwiązują.