Как защитить ключ API Rest для Parse в приложении html

Question

Я обучаюсь с Angular.js и использовал Parse в качестве внутреннего сервиса. Чтобы разместить данные в RESTful API Разбор, вы бы передать REST ключ API и идентификатор приложения в заголовке запроса, как это:

var config = {headers: {"X-Parse-REST-API-Key":"someapikey", "X-Parse-Application-Id":"someappid"}}; 

$http.post("https://api.parse.com/1/classes/myobject", obj, config).success (
      function(data) {console.log(data);} 
); 

Хотя это отлично подходит для обучения, мне интересно, как бы RESTful API для Парсинг или любой другой бэкэнд-сервис-поставщик работают в реальном приложении html. Ключ API и идентификатор приложения будут отображаться в JavaScript, и любой, достаточно умный для просмотра источника, может модифицировать данные в вашей учетной записи.

Единственный способ, с помощью которого я могу работать, это использовать прокси-сервер, который добавляет заголовок Api Key/App Id. Однако это приведет к победе в цели, заключающейся в том, что вам не придется запускать собственный серверный сервер. Я что-то упустил?

Answer 1

Анализировать предоставляет несколько ключей доступа, которые могут быть использованы с помощью различных интерфейсов:

• ключа клиента (для использования с прошивкой и Android приложений)
• Javascript ключа
• Windows Key
• REST ключа
• Главный ключ (используется для доступа к API REST, но не соответствует разрешениям ACL объекта)

При доступе к Parse с клиентского javascript вы должны использовать javascript API с ключом доступа Javascript.

С точки зрения безопасности вы не сможете запретить пользователям использовать ключ доступа, который используется JavaScript на стороне клиента. Parse обеспечивает мощное управление доступом через ACL, прикрепленные к каждому объекту, что позволяет ограничить доступ для чтения/записи к каждому классу указанным пользователям. Вы также можете запретить клиентам создавать новые классы в настройках вашего приложения. Взгляните на руководство по безопасности here.

Answer 2

Вот что вам не хватает :)

Ключи Parse.com REST/JavaScript предназначены для "из-в-природе." С помощью этих ключей невозможно обойти правила доступа к объектам или проверки до подтверждения. Только мастер-ключ может это сделать. Защитите главный ключ. Полезной аналогией является шифрование с открытым ключом: вам нужно поделиться своим открытым ключом, но защитить закрытый ключ.

Может ли кто-нибудь изменить ваши данные? Да, , но только если вы дадите им. Могут ли пользователи запрашивать данные, принадлежащие другим пользователям? Да, , но опять же, только если вы дадите им. В Parse есть несколько способов обеспечить целостность и безопасность данных.

Первое разрешение для каждого объекта. Используйте веб-интерфейс Parse.com для установки a) могут ли быть созданы классы на лету и b) разрешения CRUD для существующих классов. Один из простых шагов по защите приложения - отключить любые разрешения класса, явно не требуемые. Например, объекты, созданные на внутреннем сервере, которые не должны быть доступны для записи (или, возможно, доступны для чтения) конечными пользователями.

Второй - списки контроля доступа (ACL). Списки ACL устанавливаются на каждой записи. Они определяют, какие пользователи или роли могут читать или записывать запись. Записи без ACL являются общедоступными (любой пользователь может его найти). Если Sue создает запись, которая должна быть частной для нее, установите ACL как таковой. Том не сможет найти его без главного ключа.

Третий - это облачный код. Вы можете применять критически важные бизнес-правила и проверки данных, используя функции beforeSave/afterSave. Определите, что действительно важно, и убедитесь, что оно проверено в этих функциях. Также неплохо установить ACL явно в этих функциях. ACL могут быть переданы при создании объекта, но конечный пользователь может изменить их.

Это общее правило большого пальца для обеспечения безопасности и целостности.

• Права на объект должны быть такими же открытыми, насколько это необходимо, чтобы удовлетворить ваши требования.

• Каждая запись должна иметь ACL, если вы не уверены, что это не должно.

• Большинство ACL должны быть установлены с функциями before/afterSave.

• Любые проверки, что должен быть установлен, должен быть проверен на наличие функции before/afterSave.

Последняя вещь: темп думать о всей бизнес-логике как о «важном» и настаивать на «совершенной целостности». Это слишком много для многих приложений. Убедитесь, что у вас достаточно защиты на стороне сервера, чтобы один пользователь не мог причинить вред вам или другим вашим пользователям. Не так много смысла беспокоиться за это (кроме расходов на поддержку). Если кто-то экспериментирует с вашим приложением, но ему не преднамеренно или непреднамеренно мешают другим, возможно, они найдут совершенно новый способ его использования :).