Задача и границы решения
Приложение получает возможность читать и менять корпоративные данные. Его безопасность определяется не только входом пользователя, но и хранением доступа, проверкой запросов и журналами.
Как подойти к задаче
Запрашивайте только необходимые разрешения. Храните секреты вне публичных файлов и не передавайте их браузеру. Проверяйте источник и контекст входящих вызовов по актуальной документации платформы.
Что проверить на практике
Проверьте отказ доступа, подмену идентификатора сущности и удаление приложения. Журнал должен помогать расследованию, не превращаясь в копию клиентской базы. Ограничьте доступ к журналам и срок их хранения.
Какой ошибки избежать
Ошибка — доверять переданному из интерфейса ID пользователя как доказательству полномочий. Проверку выполняет сервер с подтверждённым контекстом. Разделяйте права оператора и технической учётной записи.
Пример для проверки на вашем проекте
Пользователь меняет ID сделки в запросе встроенного экрана. Если сервер принимает его без проверки, приложение может обойти ограничения интерфейса CRM. Поэтому запрос связывается с подтверждённым контекстом и допустимым действием. Тест включает чужую сущность и отсутствие прав. Ответ об отказе не должен раскрывать содержимое закрытой записи или параметры подключения к порталу.
Проектирование приложения
Начинаем с действия пользователя, которого не хватает в стандартном интерфейсе. Проверяем точки встраивания и доступные методы, затем согласуем прототип и границы хранения данных. Отдельно описываем авторизацию, размещение и сопровождение. Приложение должно дополнять CRM, а не создавать необъяснимую вторую копию её состояния.
Приёмка и передача
Проверяем интерфейс под разными ролями, ошибки API и восстановление доступа. Передаём исходники, параметры окружения без секретов и процедуру обновления. В документации фиксируем зависимости и ограничения. Если приложение работает с несколькими порталами, изоляция их данных проверяется как самостоятельный сценарий до запуска.