Насколько безопасны SPA-приложения?

Question

[dev123]

Недавно начал изучать тему SPA-приложений и появился вопрос по безопасности.

К примеру, есть приложение: фронтенд на Vue.js и бэкенд в виде API на Laravel. Есть раздел, в который пускаем только авторизованных пользователей. Получается при аутентификации и авторизации получаем с сервера токен, затем во фронте кладём токен например, в переменную user. Затем перед переходом в закрытый раздел делаем проверку, что-то вроде:

if (user) {
    // пускаем пользователя в закрытый раздел
}

Вопрос в том, что сейчас ведь есть много инструментов, с помощью которых можно изменить код javascript прямо в браузере и выполнить его. Может ли злоумышленник вручную добавить значение в переменную user и потом выполнить код (который выше в примере) и перейти в закрытый раздел?

Comments

[Алексей Ярков]

получаем с сервера токен, затем во фронте ложим токен например, в переменную user

Может ли злоумышленник вручную добавить значение в переменную user

Откуда у злоумышленника валидный токен с сервера?

Answer 1

[Сергей Горностаев]

Если бэкенд делал не дебил, то валидность данных и права пользователя проверяются при каждом запросе. Соответственно, злоумышленник меняет значение переменной, попадает в закрытый раздел, в котором ничего не работает.

Answer 2

[Ernest Faizullin]

Бэк должен проверять каждый запрос, валидный токен или нет (есть пакеты для Laravel которые все за вас делают)
На фронте вы не сможете обеспечить безопаснось на 100%, только на бэке

Comments

[dev123]

есть пакеты для Laravel которые все за вас делают

можете перечислить популярные пакеты?

[Ernest Faizullin]

dev123, jwt-auth самый популярный, все остальное нужно использовать с погружением в логику

Answer 3

[Арсений Матыцин]

Весь код, который загружен в клиент — дыры в безопасности бэка, даже при условии токенов, ведь все пути обращений, типы описаны.

И это актуально, если мы говорим про Rest API, который преследует логику stateless бэка. Ничего не мешает скрещивать бэк и фронт, ИМХО.

Answer 4

[Roman K]

1. На фронтенде безопасности не бывает;
2. ... А тут только один пункт.

Answer 5

[Karpion]

В данном случае надо сделать так, чтобы зловредный юзер не мог узнать никакой валидный токен другого юзера. Т.е. надо при авторизации генерировать реально случайное число (псевдослучайное - нельзя), которое бэкенд хранит у себя всё время сессии. Теперь зловредный юзер утомится подбирать токен.

Для безопасности часто делают так, что при очередном обращении нормально авторизованного юзера - ему меняют токен на новый, а старый становится недействительным.

Если юзер выходит из системы - то его токен становится недействительным.

Проверка токена делается не на клиенте, а в бэкенде. И не "перед переходом в закрытый раздел", а при каждом обращении.
Клиент только хранить токен и предъявляет его бэкенду.