Czy front/aplikacja po stronie klienta powinna weryfikować dane z serwera?

jarekr000000 napisał(a):

Nie wszystkie klienty to Web. I nie wszystkie klienty są podabne na webowe XSS, więc nadgorliwe (np. eskejpowanie) po stronie backendu może wręcz czasem napsuć.

Jak pamiętne Magic quotes w php które narobiły więcej złego niż dobrego

cerrato napisał(a):

1. apka dla firm (np. jakiś system ticketowy). Grażynka jest pracownikiem firmy o ID=352, ale serwer miał buga w logice i przesłał jej także zlecenia firm o ID od 200 do 400. Jeśli front wypluje wszystko, co dostanie od serwera, to Grażynka zobaczy także tickety innych firm. Ale w przypadku sprawdzenia danych z serwera, jeśli apka zweryfikuje ID danej firmy to może ukryć dane nie przeznaczone dla tego użytkownika, które trafiły do klienta w ramach błędu.

To już i tak po ptokach, z doświadczenia wiem że nawet panie Grażynki nauczyły się otwierać dev toolsy na stronie network i przeglądać dane. Jeśli chodzi o apkę desktopową to otworzenie fiddlera to też nie jest rocket science. Takie filtrowanie przesłanych już danych tylko wydłuży czas potrzebny do wykrycia buga i powiększy wyciek. Bardzo prawdopodobne że bug przejdzie przez wszystkie fazy testów i trafi na produkcję do czego by w ogóle nie doszło gdyby nie ta "druga linia obrony".

cerrato napisał(a):

OK, oczywiście, racja - ale jednak front może doraźnie załatać fakap, zamaskować wyciek i do tego jeszcze zgłosić serwerowi stwierdzoną nieprawidłowość.

Tak już to widzę jak taki mechanizm jest implementowany w każdym miejscu i to poprawnie. Backend nie wykrył błędu ale frontend wykrył i jeszcze to backendowi zgłosił.
Jak jesteś w stanie automatycznie wykryć taki błąd w danych to zrób to na warstwie wychodzącej w postaci middleware'u na backendzie.

Dla mnie to czysto teoretyczny przypadek bo nigdy czegoś takiego nie doświadczyłem, rozumiem że OP ma jakieś negatywne przeżycia lub jego projekt i architektura sprzyja takim błędom ale jak dla mnie to tylko proszenie się o kłopoty, wyciek danych i wielomilionowe kary.
Dużo lepiej żeby dane wyciekły jawnie do jednej osoby która to zaraz zgłosi niż żeby błąd z niewidocznym wyciekiem wisiał miesiącami i znalazł swoich adoratorów.

1. Skąd ten biedny Front ma wiedzieć, co jest prawidłowe, a co nie?
2. Mechanizm walidacji na froncie nadal może coś przepuścić, więc potrzebujemy kolejnego zabezpieczenia. Myślę, że należy zacząć od weryfikacji wyświetlanych danych przez ekrany w laptopach i monitorach.

Nie czytając jeszcze dyskusji, co do walidacji danych na froncie to zostawiłbym jedynie tę techniczną (czy np. wszystkie pola w obiekcie które są potrzebne faktycznie są, czy zgadza sie np format daty itp).

Logika pod tytułem backend wysłał coś czego w teorii nie powinien zostawiłbym po stronie backendu żeby ta logika nie wyciekała.

Moim zdaniem nie powinno się tracić czasu na walidację danych dostarczonych z backendu nawet jeżeli są to dwa odrębne byty. Po pierwsze, po to się tworzy dokumentację dla API, żeby wiedzieć co się dostaje na wyjściu i pod te konkretne dane szykuje się front. Przykładowo, kto z Was przy integracji jakiś płatności on-line waliduje to co dostaje w odpowiedzi od API PayU? To wcale nie ma sensu.

Po drugie, jeżeli jakieś API ma zwracać wartość int to ma zwracać wartość int a jeżeli nie zwraca to błąd jest w backendzie, powinno to wyjść na testach i nie powinno się w żaden inny sposób tego rozwiązywać po froncie. Załóżmy, że front zrobi sobie taką walidację i później zostają takie bzdury, że dany endpoint zamiast zwracać int zwraca (w jakimś konkretnym przypadku) literkę "a" i nikt o tym z backendu nie wie bo front "to obsłużył". A następnie przychodzi koleś do rozbudowy czegoś i standardowy tekst na początku: "Panie, a kto Panu to tak spierd... to będzie 10k bez faktury"

Po drugie, jeżeli jakieś API ma zwracać wartość int to ma zwracać wartość int a jeżeli nie zwraca to błąd jest w backendzie

@leonpro778 czy czytałeś to, co było pisane wcześniej? To nie chodzi o takie rzeczy jak sprawdzanie, czy zamiast INT dostaniesz STRING albo FLOAT, tylko o bardziej przemyślane/zaawansowane zabezpieczenia - czyli np. dostajesz dane zamówień, ale sprawdzasz czy zamówienia dotyczą tego klienta, na którego jesteś zalogowany i jeśli nie to front tego nie pokazuje.

nikt o tym z backendu nie wie bo front "to obsłużył"

Kilka razy było pisane, zarówno przeze mnie jak i innych ludzików, że taka weryfikacja, jeśli będzie negatywna, ma także powodować powiadomienie serwera - także to co napisałeś nie pasuje do wcześniejszych postów. A wręcz przeciwnie - jest duża szansa, że admini/programiści BE będą wcześniej wiedzieć o awarii, która będzie automatycznie raportowana, niż jakbyśmy mieli czekać aż p. Krysia z księgowości zgłosi kierownikowi, który pójdzie do kogoś z IT, który to dopiero przekaże odpowiedniej osobie ticket ze zgłoszeniem że jakieś dziwne dane się pojawiają w tabelce.

@cerrato - tak, czytałem ale to niewiele zmienia. Ja sprowadziłem tylko sytuację do tego, że błąd z przekazywaniem danych do frontu to błąd backendu i tam trzeba to naprawiać. Przecież takie sprawdzanie przerodzi się w końcu w absurd bo zobacz:

• z frontu idzie request o konkretną rzecz

• backend waliduje czy dane dotyczące zapytania są poprawne

• backend wysyła odpowiedź

• front waliduje odpowiedź czy jest poprawna - i niby jak to ma sprawdzić - wysyłając KOLEJNE zapytanie o poprawność danych, które już powinny być poprawne w pierwszym kroku

• podczas wysłania zapytania walidującego do backendu koło nam się zamyka bo przecież równie dobrze może być błąd w danych sprawdzających
  ... i tak w kółko

  A co do samej walidacji po froncie to jedna wielka lipa. Wystarczy, że ktoś sobie "odpyta" dany request chociażby postamanem i co... dostanie i tak dane, których nie powinien dostać.

@cerrato ale takie sprawdzanie może rodzić inne problemy. Przesuńmy trochę błąd:

User loguje się do apki i w profilu dostaje błędne id firmy do której należy. Ale jakimś cudem API zwraca zamówienia dla poprawnego id firmy. Teraz front "sprawdza" że id z profilu nie zgadza się z tym na zamówieniach i ich nie pokazuje.

Dlatego takie poprawianie backendu nie ma sensu. Po to jest kontrakt z API by nie tworzyć dodatkowej logiki na kliencie.

cerrato napisał(a):

@leonpro778 czy czytałeś to, co było pisane wcześniej? To nie chodzi o takie rzeczy jak sprawdzanie, czy zamiast INT dostaniesz STRING albo FLOAT, tylko o bardziej przemyślane/zaawansowane zabezpieczenia - czyli np. dostajesz dane zamówień, ale sprawdzasz czy zamówienia dotyczą tego klienta, na którego jesteś zalogowany i jeśli nie to front tego nie pokazuje.

@cerrato - ale nadal nie wyjaśniłeś, jak miałoby to działać. Skąd frontend ma wiedzieć czy te dane dotyczą użytkownika, na którego jest się zalogowanym?
Przecież bycie zalogowanym, to też coś, co miało miejsce na backendzie. Na frontendzie możesz wyświetlić jakieś "imię i nazwisko" użytkownika, ale ono też pochodzi z backendu. Masz jakiś token, który przesyłasz z frontendu na backend, ale ten sam przy każdym requeście, więc jak ma wybrać złe zamówienia, to znaczy, że wcześniej wysłał też złe imię i nazwisko.

No doprawdy nie rozumiem, jakby się mogło coś takiego stać. Chciałbym zobaczyć opis takiego błędu - od początku do końca.

Gorzej jak dojdzie drugi klient, który chce skorzystać z API, a pierwszy frontned już przykrył i wyfiltrował sporo błędów. :)

Rozumiem strach przed pokazaniem danych jednej firmy, innej.
Jest kilka modelów multitenancy, niektóre z nich ograniczają to ryzyko.

@Miang podała bardzo dobry argument, taka walidacja to pudrowanie noska, kosztowne pudrowanie.
Powtórzę jeszcze raz, możesz sobie zwalidować równie dobrze response, dane sesji czy sam token powinieneś już mieć w obrębie requestu.
Ale czy to ma sens?? :)

Poza tym, taka walidacja tworzy dodatkowy coupling, a tego chyba chcemy uniknąć, nie?

Gorzej jak dojdzie drugi klient, który chce skorzystać z API, a pierwszy frontned już przykrył i wyfiltrował sporo błędów

POWTARZAM:
w scenariuszu, o którym cały czas piszę, błędy wyłapane przez front będą na bieżąco zgłaszane do serwera i łatane. Także powinieneś napisać raczej coś w stylu Dojdzie drugi klient, który chce skorzystać z API, które jest sprawnie działające. bo pierwszy frontned już wyfiltrował sporo błędów, które zostały naprawione :P

Takie scenariusze są tylko w bajkach. Założenie, że OD RAZU błędy zostaną "załatane", nie, takie założenie również jest błędne. W chwili zgłoszenia błędu i tak musi minąć czas, który pozwoli owy błąd naprawić a w tym czasie drugie API które chce skorzystać z zasobów to co ma robić? Czekać?

Czemu cały czas obstawiasz przy swoim skoro dostałeś już sporo argumentów "przeciw" Założyłeś się z kimś o ten problem?

@cerrato Ale skoro można takie zabezpieczenia napisać po stronie frontu, to można dokładnie te same zabezpieczenia napisać w testach po stronie backendu. Przecież w obu przypadkach musisz ustalić jakie są wymagania, a po stronie testów zrobisz to łatwiej, bez kombinowania z kanałem zwrotnym i o błędach dowiesz się zanim kupa poleci w wentylator.

Czemu cały czas obstawiasz przy swoim skoro dostałeś już sporo argumentów "przeciw"

@leonpro778 - Ale zobacz jedną rzecz - ja nikogo nie staram się namawiać/przekonywać.

Widzę co piszą ludzie zarówno "za" jak i "przeciw". Nie pcham na siłę swojego zdania, jedynie prostuję przekłamania/niezrozumienia. Chociażby pisanie o drugim froncie, który będzie miał inne filtrowanie/w ogóle tego nie będzie robić i będzie zgrzyt. OK, rozumiem ten argument i miałoby to sens, GDYBY nie to, co pisałem wiele razy: to wykrywanie fakapów ma być chwilowe - coś się zepsuje, szybko naprawiamy. W związku z tym, po chwilowym rozjeździe (do którego, swoją drogą, nie powinno dojść, bo skoro łączymy się z jednym serwerem w ramach jednej usługi to zakładamy, że mechanizmy filtrujące/ochraniające dane po stronie frontu powinny działać podobnie) problem zostanie naprawiony i wszystkie klienty dostaną (oraz wyświetlą) takie same dane.

@piotrpo - tak, można wsadzić mechanizm sprawdzający po stronie serwera, zresztą ten wątek też się pojawił. Tylko jest to o tyle bardziej skomplikowane, że taki serwer (albo jakikolwiek inny mechanizm pilnujący) musi pamiętać które połączenie z jakim klientem jakie posiada uprawnienia, sprawdzać czy dane lecą poprawnie itp. A w przypadku pilnowania przez front sprawa jest o wiele prostsza - front dostaje info, ze jesteś zalogowany jako Zdzichu. Potem dostaje dane, ale w nich jest zaszyfrowana informacja, że są one przeznaczone dla Krysi - więc front widzi niezgodność i po prostu nie pokazuje tematów należących do Krysi. Jest to o wiele prostsze w implementacji.

A w przypadku pilnowania przez front sprawa jest o wiele prostsza - front dostaje info, ze jesteś zalogowany jako Zdzichu. Potem dostaje dane, ale w nich jest zaszyfrowana informacja, że są one przeznaczone dla Krysi - więc front widzi niezgodność i po prostu nie pokazuje tematów należących do Krysi. Jest to o wiele prostsze w implementacji.

A teraz Krysia się zwalnia i jej zadania przejmuje Zdzichu...

cerrato napisał(a):

Gorzej jak dojdzie drugi klient, który chce skorzystać z API, a pierwszy frontned już przykrył i wyfiltrował sporo błędów

POWTARZAM:
w scenariuszu, o którym cały czas piszę, błędy wyłapane przez front będą na bieżąco zgłaszane do serwera i łatane. Także powinieneś napisać raczej coś w stylu Dojdzie drugi klient, który chce skorzystać z API, które jest sprawnie działające. bo pierwszy frontned już wyfiltrował sporo błędów, które zostały naprawione :P

Dalej śmierdzi wyciekiem domeny biznesowej.

Skoro frontend jest w stanie biznesowo ocenić czy dane są poprawne (bo technicznie bazuje na kontrakcie api: pole X ma typ Y wiec to wiemy, że jest w stanie ocenić) to poszło coś nie tak i może API np. operuje zbyt ogólnymi typami (w kontekście roli zamiast enuma jest string i frontend musi dopowiadać sobie resztę itp).

Błędy czysto techniczne jak najbardziej powinny być zgłaszane (a raczej szybko powinno to wyjść samo na metrykach).

Moim zdaniem, to już pomysł z "mechanizmem zabezpieczającym" jest bzdurny. Backend nie powinien zwracać Zdzichowi danych Krysi. Rolą testów jest sprawdzenie, czy ktoś gdzieś nie zapomniał dodać jakiegoś warunku.
Dodawanie takich małych niby zabezpieczeń jest złą praktyką, bo na koniec masz niby-bezpieczeństwo, którego w żaden sposób nie jesteś w stanie audytować.
Nie chcesz, żeby dane, których właścicielem jest X zostały pokazane Y, to na GET /dane piszesz filtr, że wysyłane mają być tylko dane użytkownika wysyłającego request i koniec. Dopisujesz do tego testy getAllData... i sprawdzasz czy zwracając się po wszystkie dane dostaniesz te, które chcesz dostać, czy nie ma tam danych, których nie powinieneś dostać i czy jak wywołasz GET data/{recordId} uzupełniony odpowiednio danymi użytkownika, bez danych użytkownika i danymi innego użytkownika dostaniesz 200, 401, 403. Job done.

Chyba, że mówimy o bardziej złożonych wariantach multi tenancy, albo bardzo wrażliwych danych, to trzeba się bardziej wysilić.

cerrato napisał(a):

Czemu cały czas obstawiasz przy swoim skoro dostałeś już sporo argumentów "przeciw"

@leonpro778 - Ale zobacz jedną rzecz - ja nikogo nie staram się namawiać/przekonywać.

Widzę co piszą ludzie zarówno "za" jak i "przeciw".

A ja wcale Tobie nie zarzucam, że kogoś namawiasz. A teraz przeczytaj to co napisał @RequiredNickname oraz @piotrpo i powiedz, że nie trafiają do Ciebie te argumenty. Po prostu moim zdaniem nie chcesz dopuścić do siebie, że pisanie takich "walidatorów" po froncie jest bez sensu

@cerrato: Ale nadal to wszystko widać w devtoolsach, pudrujesz dalej. I to już jest wyciek danych. Jak odszyfrujesz te dane z poziomu frontu? Publicznym kluczem? Zagwarantuj mi, że ja tego nie zrobię.

Teoretycznie można dane na poziomie bazy szyfrować indywidualnym kluczem, przesyłac do frontu, który ten klucz sobie pozyska z jakiegoś przetestowanego endpointa, albo jakiegoś mfa po stronie użytkownika. Podejrzewam jednak, ze wrażliwość danych w tym przypadku nie usprawiedliwia takich rozwiazań.

piotrpo napisał(a):

Teoretycznie można dane na poziomie bazy szyfrować indywidualnym kluczem, przesyłac do frontu, który ten klucz sobie pozyska z jakiegoś przetestowanego endpointa, albo jakiegoś mfa po stronie użytkownika. Podejrzewam jednak, ze wrażliwość danych w tym przypadku nie usprawiedliwia takich rozwiazań.

Brzmi to zupełnie jak szyfrowanie E2E w formie hardcore, albo jak zwykła szyfrowana komunikacja w stylu HTTPS w wersji podstawowej.

Nie wiem po co nakładać dodatkową warstwę szyfrowania, które w dodatku może być zrobione dziurawo.

Jeszcze w przypadku np. obiegu poufnych dokumentów to jest zrozumiałe - tylko wtedy nie deszyfrujesz w aplikacji, użytkownik pobiera dane (np dokument) na lokalne urządzenie, deszyfruje i poniekąd bierze na klatę kwestię co z tym robić dalej.

Ogólnie to chyba zgubiłem już wątek - o co właściwie się spieracie z @cerrato ? Myślałem że wszyscy na wstępie się zgodzili że walidacje biznesowe na froncie są średnie, i dyskusja poszła w kierunku zasadności walidacji technicznych, a tu widzę że jednak nie

Tak, jest to szyfrowanie e2e i czasami się takie stosuje, np. tutaj: https://bitwarden.com/ Plus rozwiązania jest taki, że dostawca usług nie ma dostępu do danych, a w przypadku kiedy klient rezygnuje z usługi wystarczy skasować klucz szyfrujący, bo danych zwykle nie daje się skutecznie usunąć.

WeiXiao napisał(a):

@piotrpo

Backend nie ma nic usuwać. Backend ma nie utrwalić tych głupotek. jeżeli gdzieś wychwyci niebezpieczną treść wprowadzoną przez użytkownika, to ma jej nie wpuścić dalej.

Co to jest ta niebezpieczna treść? takie stringi? <script> alert('dupa') '; DROP DATABASE;?

Backend ma to zapisać w bazie i tyle. To nie są czasy budowania SQLa za pomocą łączenia stringów i braku narzędzi do bezpiecznego wyrenderowania czegoś na frontendzie.

Następnie backend zwraca to na front, a front ma to bezpiecznie wyrenderować (zakładając webowy frontend).

Ta cała "input sanitization" to jakiś zbiór mitów i pomysłów na dzikie obrabianie stringów zamiast zrobienia czegoś poprawnie

https://benhoyt.com/writings/dont-sanitize-do-escape/

https://kevinsmith.io/sanitize-your-inputs/

Z tym co napisales sie zgadzam wlacznie z input sanitization.
ale...

W pewnych okolicznosciach input nie tyle sanitization co validation jest wskazane.

Problem z bezpiecznym renderowaniem, co wbrew pozorom nie dotyczy to tylko browsera, polega na tym ze XSS bylo w top3 OWASP miedzy 2017 a 2021, a pewnie obecnie jest w top10. Podejrzewam ze narastajacy problem zmusil ludzi do zabezpieczanai sie po wielu stronach , co w istocie jest glupie, ale uzasadnione w niektorych przypadkach np glupim DDLem bazy na ktora nie maja wplywu.

Ponadto w swiecie narastajacego zjawiska naukowcow piszacych w pythonie a potem z powodu wygaszenia grantow piszacych komercyjnie web nadal nie marginalizowalbym tego problemu: Lepiej niech se to przesanityzuje po requescie, przed insertem, a potem jeszcze przed wyswietleniem niz zeby nie robil tego w ogole :) Jak ktos lepeij czuje sie w 3 gumkach to korzysc dla gospodarki ;)

To nie są czasy budowania SQLa za pomocą łączenia stringów i braku narzędzi do bezpiecznego wyrenderowania czegoś na frontendzie.

Niby nie, ale nadal mają zastosowanie WAF-y których zadaniem jest właśnie pierwsza linia obrony - blokowanie prób przesłania <script>alert(1)</script> mimo iż z perspektywy bazy danych i frontendu, może to być poprawny adres zamieszkania klienta, albo uwagi do zamówienia :)

zasiedzony napisał(a):

Ponadto w swiecie narastajacego zjawiska naukowcow piszacych w pythonie a potem z powodu wygaszenia grantow piszacych komercyjnie web nadal nie marginalizowalbym tego problemu: Lepiej niech se to przesanityzuje po requescie, przed insertem, a potem jeszcze przed wyswietleniem niz zeby nie robil tego w ogole :) Jak ktos lepeij czuje sie w 3 gumkach to korzysc dla gospodarki ;)

no to pozostaje pytanie, co faktycznie zapiszesz do bazy?

tak wyescapowany string?

Fajnie się później będzie pracowało z takimi danymi, wybitnie wygodne :D

zasiedzony napisał(a):

Podejrzewam ze narastajacy problem zmusil ludzi do zabezpieczanai sie po wielu stronach , co w istocie jest glupie, ale uzasadnione w niektorych przypadkach np glupim DDLem bazy na ktora nie maja wplywu.

Nie zgodzę się, że zabezpieczanie się z kilku stron, tudzież na wielu warstwach, jest głupie. Bywa robione w głupi sposób, lub inaczej mówiąc nieprofesjonalnie, ale to nie wynika z idei stosowania wielu warstw zabezpieczeń, tylko z braku profesjonalizmu i stosowania niesprawdzonych, błędnych lub przestarzałych praktyk.

Defense in depth to jest obecnie podstawa i raczej nie zaufałbym komuś mówiącemu, że takie podejście jest głupie. Głupim jest zakładanie, że wymyśliliśmy albo kupiliśmy takie super-w-pytę zabezpieczenie, że mucha nie przejdzie. Raz firma wydała kupę kasy na rozwiązanie SIEM, a ataki przechodziły działowi Security pod nosem - a w dodatku twierdzili, że przecież to niemożliwe, by jakiś atak im przeszedł, więc musiałem chyba sfabrykować logi a ja i koledzy jako zwykli, głupawi deweloperzy zebraliśmy logi, metryki, raporty z logów, listę przejętych kont, wektory ataku i koniec końców panowie z Security po wielu dniach przepychanek raczyli interweniować.

sorry, że dopisuję się do tematu po pół roku od założenia, ale to chyba nie przestępstwo.

po pierwsze, jeśli robicie jakąś stronę internetową to możecie z góry założyć, że ktoś zrobi harvestera / scrapera, który będzie w stanie przemielić masę danych szybko. nie trzeba do tego nawet upubliczniać dokumentacji czy nawet jej tworzyć. spryciarz może po prostu podejrzeć jakie żądania są robione do serwera i napisać na kolanie coś co to imituje. w naszym projekcie to już się zdarzyło, a nasz portal jest dostępny tylko dla klientów, którzy płacą (więc grono spryciarzy mających dostęp do danych jest wiele rzędów wielkości mniejsze niż zbiór wszystkich hakierów działających w internecie).

po drugie:

cerrato napisał(a):

Ma wielkie znaczenie to, gdzie tą walidację wsadzimy: jeśli sprawdzam na poziomie aplikacji u klienta/użytkownika końcowego, to sprawdzam tylko w zakresie danych, które ta aplikacja otrzyma, po prostu - dodajemy w miarę prostą logikę do aplikacji. Za to zrobienie proxy na serwerze wymaga filtrowania całego ruchu, pamiętania która apka z jakimi poświadczeniami działa, kto co powinien móc widzieć, kontrola czy przesyłane dane są na pewno przewidziane dla danej końcówki itp. Moim zdaniem to jest 100x więcej zamieszania.

Po prostu - na froncie dodajemy dodatkowe sprawdzenie po stronie aplikacji u klienta, ale nie jest to nowy byt, tylko poszerzenie czegoś, co mamy. Po stronie serwera - tworzymy nowy byt (jakiś middleware, proxy, API czy jakkolwiek byśmy to nazwali).

moim zdaniem to wstawianie tej zduplikowanej logiki po stronie klienta wprowadza więcej zamieszania niż wstawianie tego na backend. backend wie z którym użytkownikiem ma do czynienia, bo klient (przeglądarka czy dowolny inny) wysyła identyfikator sesji, a mając sesję wiadomo, o dane którego użytkownika chodzi (czyli można wyciągnąć prosto jego idka). to backend powinien kontrolować kto do czego ma dostęp i ma takie dane, nie frontend. frontend jedynie decyduje czy ukryć fragment ui, który i tak by nie działał, ale jak pokaże coś co jest zablokowane na backendie dla danego użytkownika to i tak wiele się nie stanie.

wstawianie zduplikowanej logiki na frontend jest kiepskie ponieważ w takiej sytuacji jest większe sprzężenie między backendem, a frontendem. be i fe muszą wtedy synchronizować reguły sprawdzania poprawności biznesowej danych. be i fe stoją po przeciwnych stronach systemu, tzn. organizacyjnie bardzo daleko od siebie w porównaniu do dwóch apek strojących na backendzie. jeśli zduplikowaną logikę wstawiamy na backend (obojętnie czy do nowej apki czy poupychaną do już istniejących czy może do testów albo czegokolwiek innego) tam gdzie oryginalne apki serwujące dane, to przynajmniej mamy usprawniony proces rozwoju backendu jako całości, bo jeden zespół (sami backendowcy) ogarnia te (zduplikowane) warstwy filtrowania danych.

ogólnie całość dość dobrze podsumowuje ta wypowiedź:

jarekr000000 napisał(a):

Nie ma sensu dodatkowe filtrowanie danych po stronie frontu.
To dodatkowy kod, który trzeba utrzymywać, kolejne potencjalne błędy.
(...)
Są przypadki kiedy mamy paranoje security (np. dane medyczne), ale wtedy też dodatkowe filtrowanie na froncie... to i tak za późno. Są dodatkowe filtry/reguły, które można umieścić w ramach API Gateway itd. Czyli po tym jak backend wypluje dane, to muszą jeszcze przejść przez dodatkowy zestaw reguł (ale to naprawde niszowe sytuacje - raz pracowałem przy takim systemie - to było straszne, ale niestety miało sens).

wracając jeszcze do prób zdefiniowana o co chodzi w tym wątku to są chyba dwie kwestie:

• czy robić dodatkowe (zduplikowane) warstwy filtrowania (np. te wykrywające dane, do których użytkownik nie powinien mieć dostępu)?
• (jeśli odpowiedź na powyższe pytanie jest twierdząca to) czy te dodatkowe warstwy filtrowania umieścić na backendzie czy na frontendzie?

jeśli zdecydujemy, że w danej sytuacji nie warto robić dodatkowej warstwy filtrującej to sprawa jest prosta. natomiast jeśli chcemy mieć dodatkowe zabezpieczenie to trzeba rozważyć wady i zalety umieszczania go na frontendzie lub backendzie. porównanie wygląda mniej więcej tak:

• dodatkowe filtrowanie po stronie frontendu to filtrowanie robione zbyt późno, bo dane potencjalnie dostały się już w niepowołane ręce (łatwo jest rejestrować ruch między przeglądarką, a serwerem), więc nie nadaje się do danych skrajnie wrażliwych. dodatkowe filtrowanie po stronie backendu zabezpiecza przed dostaniem się danych w niepowołane ręce bez względu na to czy ten ktoś polega tylko na widoku generowanym przez frontend czy analizuje cały ruch od serwera (a to jest przecież proste). w jakich sytuacjach nasze dane są na tyle wrażliwe, by uzasadniało to robienie zduplikowanych warstw filtrowania, ale nie na tyle wrażliwe, by przejmować się czy faktycznie zablokujemy niepowołany dostęp od razu?
• tak w ogóle to sam sygnał od frontendu, że coś jest źle też można sfałszować i wywołać fałszywy alarm po stronie backendu / systemu. co wtedy? system automatycznie się wyłączy, bo jakiś dowcipniś zasygnalizował błąd bezpieczeństwa, którego de facto nie ma? a może backend ma mieć warstwę filtrującą dla sygnałów z frontendu o uszkodzonym filtrowaniu? trochę taka incepcja. a może frontend będzie mieć błąd w tej zduplikowanej warstwie filtrowania i zgłosi błąd, którego nie ma? co z race conditions? frontend np. wyciąga listę postów dla użytkownika, potem ktoś usuwa dostep do pewnej kategorii, potem frontend wyciąga listę kategorii dostępnych dla użytkownika i wychodzi na to, że użytkownik dostał posty, których nie powinien widzieć. jak to rozwiązać po stronie alarmującego frontendu?
• robienie dodatkowego filtrowania (na frontendzie) w maksymalnej odległości od oryginalnego filtrowania (apka backendowa wyciągające dane z bazy) to silne sprzężenie (tight coupling) procesu rozwoju backendu i frontendu. takie coś może miałoby jakiś tam sens, gdyby cały zespół był złożony z fullstacków ogarniających jednocześnie zmiany w be i fe dotyczące jednej zmiany biznesowej. w przypadku osobnych zespołów backendowców i frontendowców taka zduplikowana logika to zwiększone tarcie między zespołami i problemy z błędną interpretacją. ogólnie jest tak, że backendowcy nie są jakoś super na bieżąco z tym co robią frontendowcy i vice versa. to samo dotyczy code review - backendowcy nie robią kompleksowych przeglądów frontendowcom i vice versa. stąd jest duże prawdopodobieństwo, że ta zduplikowana logika, rozrzucona między backendem i frontendem, będzie faktycznie mieć odmienną semantykę (z większym prawdopodobieństwem, że ta po stronie frontendu będzie zła, bo ta jest przecież tylko dodatkowa) i często będzie działać (przynajmniej pozornie) poprawnie tylko dzięki zbiegowi okoliczności.