Mandiant открыла исходники инструмента для предотвращения утечек из-за ошибок конфигурации Salesforce

13.01.2026 • The Register

Mandiant выпустила open source-инструмент AuraInspector для поиска опасных misconfiguration в Salesforce, которые могут приводить к утечкам данных. Ключевой посыл: проблема чаще в настройках доступа, а не в «уязвимости» самой платформы.

Инструмент AuraInspector нацелен на проверки контроля доступа в Salesforce Aura — UI-фреймворке для сайтов Experience Cloud.
В тексте приводится пример: при доступе неаутентифицированных пользователей ко всем записям объекта Salesforce Account возможна эксфильтрация данных через метод getItems.
Mandiant называет это «распространённой misconfiguration», встречающейся в реальных расследованиях и проверках.
Ограничение выборки «до 2 000 записей за запрос» может обходиться изменением сортировки; метод описывается как непоследовательный и потенциально дающий дубликаты.
Ещё один описанный обход связан со злоупотреблением GraphQL API, который доступен по умолчанию для guest-аккаунтов.
Mandiant подчёркивает, что операции AuraInspector read-only и инструмент не вносит изменения в инстанс Salesforce.

Почему это важно: История про то, как сложность UI-слоя и прав доступа в корпоративных платформах может превращать «обычные настройки» в источник утечек. В описании инструмента акцент сделан на типовые сценарии злоупотребления, включая доступ гостевых пользователей и особенности API. Для команд, которые опираются на Experience Cloud и Aura, это сигнал к ревизии прав и к более строгому моделированию гостевого доступа.

На что обратить внимание: В тексте отдельно говорится, что GraphQL API доступен по умолчанию для guest-аккаунтов, и что Salesforce считает API не уязвимостью при корректных настройках доступа. Также отмечено, что Aura широко используется для legacy-функциональности даже при переходе на Lightning Web Components. Практический «следующий шаг» здесь подразумевается как проверка того, какие объекты и методы доступны гостям, и насколько ограничения выборки действительно сдерживают эксфильтрацию в конкретной конфигурации, а не на уровне предположений.

Коротко

AuraInspector фокусируется на misconfiguration в Salesforce Aura: по тексту риск связан с настройками контроля доступа, а не с «врождённой» небезопасностью компонентов.
В статье описаны два пути злоупотребления: обход лимита выборки через сортировку и использование GraphQL API, доступного по умолчанию гостевым аккаунтам.
Инструмент заявлен как read-only и предназначен для автоматизации проверок и рекомендаций по ремедиации без изменения конфигурации Salesforce-инстанса.
На практике подобные сюжеты обычно означают, что модель «guest-доступа» требует отдельного дизайна и постоянных ревизий прав по объектам и методам.
Если в организации остаются legacy-сценарии на Aura, это повышает цену ошибок конфигурации: миграция на новые компоненты не отменяет старые поверхности риска.

FAQ

Зачем это важно, если речь идёт не об уязвимости Salesforce, а о неверных настройках доступа в Aura и Experience Cloud?

Потому что misconfiguration может приводить к утечкам данных так же эффективно, как и «классическая» уязвимость. Текст подчёркивает, что при правильной настройке доступа API не считается проблемой.

Что именно делает AuraInspector и на какой части Salesforce он сфокусирован по описанию в статье?

По тексту, инструмент ищет проблемы контроля доступа в Salesforce Aura — UI-фреймворке для сайтов Experience Cloud, и помогает выявлять сценарии потенциального злоупотребления.

Какие механики обхода ограничений на выборку данных приводятся в статье в качестве примеров злоупотребления?

Описаны обход лимита «до 2 000 записей» через изменение сортировки и возможность злоупотребления GraphQL API, доступным по умолчанию для guest-аккаунтов.

Вносит ли AuraInspector изменения в Salesforce-инстанс при выполнении проверок, согласно заявлению Mandiant?

Нет. В тексте отдельно сказано, что операции инструмента read-only и он не модифицирует инстансы Salesforce.

PubMag