Какие потери возникают, если реализовать авторизацию через client-side rendering вместо SSR? Почему в таких случаях часто выбирают SSR?

Потери при авторизации через CSR

Когда авторизация реализована на клиенте (CSR), весь код проверки прав и токены доступа могут быть извлечены из JavaScript-бандла. Это делает систему уязвимой для атак, таких как перехват токенов или подмена ролей. Кроме того, при CSR первый рендеринг задерживается, так как браузер должен загрузить и выполнить JS, что ухудшает восприятие скорости.

Преимущества SSR

SSR выполняет проверку авторизации на сервере до отправки HTML. Это скрывает логику от клиента и позволяет сразу вернуть защищённый контент. Пример на Node.js с Express:

app.get('/dashboard', (req, res) => {
  const token = req.cookies.token;
  if (!token) return res.redirect('/login');
  const user = verifyToken(token);
  if (!user) return res.status(403).send('Forbidden');
  const html = renderDashboard(user);
  res.send(html);
});

Здесь токен проверяется на сервере, и только после этого генерируется HTML. Это предотвращает утечку данных и ускоряет первый рендеринг.

Вывод

SSR предпочтителен для приложений с высокими требованиями к безопасности и производительности, особенно при работе с конфиденциальными данными. CSR подходит для публичных интерфейсов, где скорость разработки важнее защиты.