@dev123

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

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

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

Вопрос в том, что сейчас ведь есть много инструментов, с помощью которых можно изменить код javascript прямо в браузере и выполнить его. Может ли злоумышленник вручную добавить значение в переменную user и потом выполнить код (который выше в примере) и перейти в закрытый раздел?
  • Вопрос задан
  • 410 просмотров
Решения вопроса 2
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
Если бэкенд делал не дебил, то валидность данных и права пользователя проверяются при каждом запросе. Соответственно, злоумышленник меняет значение переменной, попадает в закрытый раздел, в котором ничего не работает.
Ответ написан
erniesto77
@erniesto77
oop, mvc, rb, py, php, js
Бэк должен проверять каждый запрос, валидный токен или нет (есть пакеты для Laravel которые все за вас делают)
На фронте вы не сможете обеспечить безопаснось на 100%, только на бэке
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
@deliro
Агрессивное программирование
1. На фронтенде безопасности не бывает;
2. ... А тут только один пункт.
Ответ написан
ArsenyMatytsyn
@ArsenyMatytsyn
CEO iAmStudio, предприниматель.
Весь код, который загружен в клиент — дыры в безопасности бэка, даже при условии токенов, ведь все пути обращений, типы описаны.

И это актуально, если мы говорим про Rest API, который преследует логику stateless бэка. Ничего не мешает скрещивать бэк и фронт, ИМХО.
Ответ написан
@Karpion
В данном случае надо сделать так, чтобы зловредный юзер не мог узнать никакой валидный токен другого юзера. Т.е. надо при авторизации генерировать реально случайное число (псевдослучайное - нельзя), которое бэкенд хранит у себя всё время сессии. Теперь зловредный юзер утомится подбирать токен.

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы