SPA будет иметь все страницы структуры (html и javascript код для оформления страниц), но, очевидно, не данные. Данные будут загружаться в последующих запросах ajax, и в этом суть. Чтобы загрузить фактические данные, пользователь должен будет пройти аутентификацию на сервере, и тогда вся защита будет реализована на стороне сервера. Неавторизованный пользователь не должен иметь доступа к данным с сервера. Но идея в том, что то, как выглядят страницы, не секрет, что любой может взглянуть на страницы SPA без данных , и это нормально.
Ну, и вот тут-то и есть тот улов, который люди часто упускают из виду. HTML - это одно, но в SPA есть весь javascript, который может получить доступ ко всем данным. По сути, код SPA - это документация API, если хотите, список возможных запросов, которые может обработать серверная часть. Конечно, все это должно быть защищено на стороне сервера, но это не всегда так, люди делают ошибки. Имея такую «документацию», что и SPA, злоумышленнику может быть гораздо проще оценить безопасность на стороне сервера и найти недостатки авторизации / контроля доступа в коде на стороне сервера, которые могут обеспечить доступ к данным, которые не должны быть доступны для атакующий.
Короче говоря, иметь доступ к тому, как страницы выглядят (без данных), должно быть в порядке. Однако отказ от того, как именно работает API, может в определенных сценариях помочь злоумышленнику и, следовательно, добавляет некоторый риск, который присущ SPA.
Следует отметить, однако, что это не должно иметь значения. Поскольку безопасность по неясности не должна использоваться (т. Е. Не должно быть секретом, как все работает, секретными должны быть только такие вещи, как учетные данные), должно быть хорошо, чтобы кто-нибудь знал весь javascript или полную документацию API. Однако реальный мир не всегда так идеалистичен. Часто злоумышленники не знают, как все работает, и это может оказать реальную помощь, например, для анализа SPA, потому что люди, которые пишут внутренний код, действительно делают ошибки. В других случаях API является общедоступным и в любом случае задокументирован, и в этом случае наличие SPA не представляет дальнейшего риска.
Если вы устанавливаете SPA за аутентификацией (загружать код SPA могут только аутентифицированные пользователи), это значительно усложняет доступ к CDN, хотя я думаю, что некоторые сети доставки контента поддерживают некоторый уровень аутентификации.
Тем не менее, есть реальная выгода от наличия отдельной (простой старой html) страницы входа вне SPA. Если у вас есть страница входа в SPA, вы можете получить только токен доступа (идентификатор сеанса и т. Д.) В javascript, что означает, что он будет доступен для javascript, и вы можете сохранить его только в localStorage, или простой не только cookie-файл. Это может легко привести к краже токена аутентификации через межсайтовый скриптинг (XSS). Более безопасный вариант - иметь отдельную страницу входа в систему, которая устанавливает маркер аутентификации как файл cookie httpOnly, недоступный для любого javascript и, следовательно, защищенный от XSS. Обратите внимание, что это создает риск CSRF, с которым вам придется иметь дело, а не с идентификатором токена / сеанса, отправляемым как заголовок запроса.
Во многих случаях наличие логина в SPA и сохранение токена аутентификации в localStorage приемлемо, но это должно быть обоснованное решение, и вы должны знать о риске (XSS против CSRF в другом случае).