Если вас не испугала первая часть, предлагаю продолжить разговор о механизмах безопасности Meteor. Начав с loginToken, выдаваемого клиенту, правил allow/deny при модификации базы данных клиентом, коснемся доверенного и недоверенного кода, серверных методов, использования HTTPS и пакета force-ssl, пакета browser-policy (Content Security Policy и X-Frame-Options), и закончим встроенным механизмом валидации данных (функция check() и пакет audit-arguments-check).

Для разработки приложений фреймворка Meteor существует некоторое число приемов и средств, предназначенных для обеспечения безопасности. В первой части мы поговорим о более известных вещах — скрытии серверной части кода, пакетах autopublish / insecure, скрытии полей коллекций при публикации и встроенной системе учетных записей, заглянув внутрь коллекции Meteor.users. Во второй — про loginToken, выдаваемый клиенту, правила allow/deny при модификации базы данных клиентом, доверенном и недоверенном коде, серверных методах, HTTPS, пакете force-ssl и пакете browser-policy (Content Security Policy и X-Frame-Options), встроенном механизме валидации данных (функция check() и пакет audit-arguments-check).