Jak zabezpieczyć aplikację REST

Mam rest api wystawione w spring boot do którego strzela front end napisany w Vue. Jak teraz bezpiecznie zaimplementować autoryzację użytkowników? Z tego co czytałem to klasycznej sesji przez cookies nie zaimplementuje (chyba, że czegoś nie rozumiem i jest to możliwe) - wszystkie tutoriale, które widziałem używają springa i frontu server side rendering (na przykład thymeleaf). Czy pozostaje mi tylko JWT? Jeżeli tak to wiem, że można to rozegrać na 2 sposoby.

• JWT trzymany w session storage. Wszędzie odradzany, łatwa podatność na XSS. Czyli odpada.
• JWT trzymany w cookie httpOnly. Wtedy trzeba się martwić o CSRF. Pytanie czy żeby zabezpieczyć się przed CSRF wystarczy ustawienie na cookie sameSite=strict? Teoria mówi, że tak. W dokumentacji jest informacja, że gdy zapytanie do mojego serwera zostanie wygenerowane z innej domeny niż ta, dla której ciasteczko zostało utworzone, przeglądarka nie dołączy takiego ciasteczka do żądania. Pytanie czy w praktyce rzeczywiście tak to wygląda i nas zabezpiecza.

Widziałem, jeszcze, że są CSRF tokeny, ale nie bardzo rozumiem ideę działania. To jest możliwe przy client-side front typu Vue, React? Jeżeli backend ma zapisywać csrf token w cookie XSRF-TOKEN i front ma dołączać ten token przy każdym newralgicznym strzale do backendu to co stoi na przeszkodzie atakującemu wyjęcie sobie tego ciasteczka z tokenem tak samo jakby wyciągał JWT z cookie przy klasycznym ataku CSRF? Prosiłbym i jakieś nakierowanie w tym temacie i wskazanie błędów w moim toku myślenia.

Trochę nie mój temat, ale napiszę jak ja to rozumiem.
Jeżeli twoja aplikacja jest podatna na XSS to jesteś w czarnej d... Jeżeli ktoś jest w stanie wbić się w jej działanie, to już niczego więcej nie zabezpieczysz.

CSRF polega na tym, że masz legalny endpoint:

POST https://bank.com/transfer

i wysyłasz tam dane

{
  "recipientAccount":"1234..."
  "amount":100
}

Jak endpoint dostanie te dane, to wykona przelew na wskazane konto.

Teraz atakujący umieszcza gdzieś stronkę z formularzem i spreparowanym pod siebie poleceniem przelewu. Użytkownik skuszony reklamą środka na powiększenie penisa, wygranym iPhonem, czy co tam aktualnie jest modne wśród scamerów wchodzi na https://havebiggerpenis.com wyświetla mu się "cokolwiek", klika guzik i formularz zostaje wysłany. Ponieważ jesteś zalogowany w swoim banku, to przeglądarka dołączy do tego dane uwierzytelniające/autoryzujące żądanie z cookies i backend obsłuży to żądanie jak każde inne.
Obrona przed CSRF polega na wymuszeniu takiego działania systemu, żeby nie dało się wykonać krytycznej akcji pojedynczym żądaniem http. Jednym ze sposobów jest zmiana endpointu tak:

POST https://bank.com/transfer?csrf-token={token}

i dołożenie dodatkowego (uwierzytelnianego) endpointu

GET https://bank.com/csrfToken

Teraz, jeżeli użytkownik kliknie "lewego" linka, to żądanie zostanie odrzucone, bo nie zawiera prawidłowego tokenu.
Może zmienić link na lewej stronie, żeby pobierał token, ale rezultat trafia do użytkownika, a nie do atakującego, czyli nadal jest bezpiecznie.
Sposób zaprojektowania API po stronie serwera, wymusza wykonanie 2 niezależnych żądań do serwera, a wektor ataku wymusza ograniczenie całego ataku do położenia nieświadomemu użytkownikowi spreparowanego linka.

Okej kumam już z tym tokenem. Ale czytając o tych CSRF tokenach nigdzie jakoś nie natrafiłem na info, żeby wykonywać dodatkowy strzał po niego. Tylko, że teraz z każdego jednego requestu zrobią nam się dwa?