#node.js #reactjs #api #express #security
#node.js #reactjs #API #экспресс #Безопасность
Вопрос:
Я разработал простой REST API с использованием ExpressJS. Я использую React в качестве своего клиентского приложения. Итак, проблема в том, что любой может видеть мои конечные точки API, потому что приложение react находится на стороне клиента. Таким образом, они также смогут делать запросы и извлекать данные из моего REST API. (Возможно, они будут создавать свои собственные клиентские приложения, используя мой API.) Я видел несколько вопросов по этому поводу и не смог найти исчерпывающего ответа. Как следует решать такого рода проблемы безопасности? Можно ли предоставить доступ к API только моему клиентскому приложению? Если нет, то как крупные бренды, использующие REST API, предотвращают это? (Кроме того, у меня также нет сценария аутентификации пользователя в моем продукте. Люди могут просто посещать и использовать веб-сайт. Им не нужно регистрироваться).
Комментарии:
1. Итак, действуйте в соответствии с тем самым последним предложением, которое у вас в скобках: добавьте аутентификацию пользователя в свою систему. Сценарий, который вы набрасываете, решается путем проверки того, что разрешены соединения с правильными учетными данными (например, через ключ API / токен аутентификации, а не путем передачи пользователя / прохода каждый раз), а все остальные получают 403.
2. Затем вы добавляете это в свой пост, и ответ звучит так: «Убедитесь, что настроили правильные правила CORS и CSP», а также убедитесь, что ответы API получают только соединения с активным сеансом (так что даже без авторизации: используйте управление сеансами).
3. Для CORS express создает собственную библиотеку (см. expressjs.com/en/resources/middleware/cors.html ), для CSP и множества других уровней безопасности, таких как HSTS, фильтрация XSS и т. Д., Вы обычно используете шлем .
4. как сказано, нет. Представьте, что вы добавили сеансы, в которых затем был токен одноразового использования, затем скрипт scrapper мог сначала получить токен, представив, что у вас есть файлы cookie или какой-либо другой токен, затем scrapper мог сначала его удалить, представив, что вам нужно войти в систему, тогда scrapper может войти в систему первым. Если ваш API широко открыт, вы ничего не можете сделать, кроме поиска IP-адреса, можете сравнить его со списком известных хостинг-провайдеров, подсчитать использование с одного IP-адреса, т.Е. Один IP-адрес, похоже, зарабатывает 100 тыс. в день и входит в несколько учетных записей, или, если ни одна учетная запись не использует несколькоодноразовые токены сразу и т. Д.
5. Клиентское приложение, напрямую подключающееся к вашему API, отличается, CORS защитит это, но вы ничего не можете сделать для защиты от чего-то вроде
app.use('/his-api', proxy('https://yoursite.com'))или пользовательского скрипта, который выполняет логику на пути, т.Е./login/registerВыполняет вызов с использованием node-fetch для вашего API для входа / регистрации, а затем передает заголовкии все это хорошо для клиента. Защита от удаления действительно может быть выполнена только путем определения, является ли IP-адрес утилизатором, хотя местоположение IP или злоупотребление, например, один IP зарегистрировался 100 раз и т. Д
Ответ №1:
Аутентификация может быть способом, но ее можно обойти. Другой способ — вы можете создать прокси-сервер, который строго блокирует перекрестные исходные запросы, следовательно, он блокирует запросы от других доменов для отправки запроса к вашему API, и вы можете выполнить свой вызов API с этого прокси-сервера. Таким образом, конечная точка вашего сервера API также не будет скомпрометирована.
Ответ №2:
Если, как вы указываете в своем комментарии, речь идет о том, что пользователям на вашем собственном веб-сайте разрешено использовать API вашего сайта, запрещая использование за пределами сайта (например, на других веб-сайтах, wget / curl и т. Д.), Тогда вам необходимо убедиться, что установлены надлежащие правила CORS (чтобы запретить использование из разных источников вашего API), а также правила CSP (для предотвращения проксирования вашего API с помощью пользовательских скриптов), и вы также убедитесь, что разрешаете вызовы API только из соединений с активным сеансом (поэтому, даже если вы не хотите аутентификации пользователя: используйте диспетчер сеансов, чтобы вы могли определить, кто-то приземлился на вашем сайте и получил сеансовый файл cookie, установленный до того, как они начали вызывать конечные точки API).
Управление сеансами и CORS поставляются с самим express (см. https://expressjs.com/en/resources/middleware/session.html и https://expressjs.com/en/resources/middleware/cors.html ), для CSP и множества других уровней безопасности, таких как HSTS, фильтрация XSS и т. Д., Вы обычно используете шлем.