Jak ktoś kumaty z dostateczną ilością wolnego czasu zobaczy to w kodzie twojej strony, to się przed tym nie zabezpieczysz . <- ta kropka jest wyboldowana, ale nie widać.
Podstawowa zasada pisania czegokolwiek po stronie serwera, to nie wolno ufać, że cokolwiek dostajesz od klienta/przeglądarki pochodzi z uprawnionej aplikacji/strony internetowej.
Jeżeli masz skrypt, który nie powinien być wywoływany z zewnątrz, to nie powinien być widoczny z zewnątrz. Udostępnianie przypadkowych endpointów to taka trochę masakra (nic osobistego, zwyczajne stwierdzenie faktu).
Jeżeli masz jakiś endpoint, który ma być widoczny z zewnątrz, jest widoczny z zewnątrz i powinien wymagać uwierzytelniania, bo robi coś ważnego (dajmy na to powoduje wykonanie przelewu...) to powinien zostać jakoś zabezpieczony przed atakami CSRF. Czym jest CSRF? Jesteś zalogowany do swojego banku i bank ci ufa. Na innej stronie (nawet nie lewej, wystarczy, że jest podatna na ataki XSS lub podobne) ktoś wstawia kawałek kodu, który wywołuje:
POST https://twojbank.com
{
"targetAccount":"numer konta atakującego",
"amount":""
}
Ten kod wykona się w innej zakładce, ale w przeglądarce, do której jesteś zalogowany, zostaną więc dołożone wszystkie cookies, które powinny pójść pod ten adres.
Żeby temu zapobiec możesz wprowadzić jakiś tam typ tokenów anty-CSRF, czyli masz zabezpieczony endpoint, z którego pobierasz token, oraz sprawdzasz poprawność tego tokenu (tutaj nie zgadzam się z @Riddle, że trzeba ten token pamiętać, wystarczy, że jest się w stanie potwierdzić jego autentyczność).
Ps.
Ogólnie, to jestem trochę przerażony powszechną wśród programistów ignorancją w zakresie bezpieczeństwa. Szczególnie, że obecnie jakieś 99.999% aplikacji z tej łączności przez internet korzysta. I nie jest to przytyk pod kątem OP'a, bo ostatnio kandydat na stanowisko architekta nie był w stanie opowiedzieć czym jest XSS czy CSRF. Znaczy powiedział, że "są skanery, które sprawdzają kod pod kątem podatności na ataki".
