Ответ 1
Все, что приложение javascript может делать в клиенте браузера, может быть замечено и сделано кем-то другим для доступа к вашему серверному серверу REST API за пределами вашего приложения.
Фактически, тот факт, что клиентское приложение реализовано на JavaScript, незначителен - любое приложение, которое выполняется на машине вне вашего контроля, не может полностью доверять. Немного сложнее переделать встроенный код exectuable, чем ViewSource в javascript-приложении, но не невозможно. Никогда не полагайтесь на безопасность безвестности.
Ваш лучший вариант - заставить приложение браузера потребовать от конечного пользователя входа в систему и получения токена аутентификации от доверенного поставщика удостоверений и представить этот токен аутентификации в каждом запросе, которое приложение-браузер делает в REST API. Затем REST API может проверить токен аутентификации, чтобы узнать, принадлежит ли он доверенному провайдеру и разрешен ли пользователю, указанному внутри токена, использовать REST API.
Это связывает авторизацию вызовов API REST с пользователем, а не с приложением, и использует секреты (учетные данные пользователя), которые не находятся в приложении браузера для всего мира.
С помощью этого вы можете ограничить доступ к вашему REST API на основе того, какой пользователь выполняет вызов. Вы также можете фильтровать доступ, основываясь на том, какое приложение выполняет запрос, но это должно быть второстепенным, а не основным фактором безопасности, поскольку для описания приложения проще копировать, чем учетные данные пользователя.
Другой вариант может заключаться в том, чтобы ваш веб-сервер выступал в качестве прокси-сервера для службы REST API, чтобы браузерное приложение проходило через веб-сервер для получения данных из REST API. Это может быть жизнеспособным, если приложение-браузер поддерживает состояние сеанса, которое веб-сервер может проверить, чтобы определить, что запрос находится в приложении bona-fide, а не от кого-то другого. Хотя это может позволить вам сохранить REST API в общедоступной сети, это действительно не изменяет вашу проблему авторизации - вы только что переместили ее на веб-сервер, где у вас может быть больше контекста сеанса, чтобы отличить запрос в приложении от запрос нарушителя. Тонкий в лучшем случае, не рекомендуется, если вы действительно не уверены в состоянии сеанса вашего приложения.
Независимо от того, какое решение вы выбираете, факт остается фактом: если ваш REST API доступен из клиентского приложения (браузера или иным образом), он является общедоступным API REST и должен рассматриваться (и укрепляться) как таковой. Существует нет такой вещи, как частный веб-API, доступ к которому можно получить с клиентской машины.