Защита сервера MCP

описана редакция 2026-07-28, сверено со спецификацией 4 октября 2026

Сервер обязан	Где
проверять все входные данные инструмента	Tools
разграничивать доступ к инструментам	Tools
ограничивать частоту вызовов инструментов	Tools
очищать результат инструмента перед выдачей	Tools
проверять все адреса ресурсов	Resources
очищать пути файлов, чтобы запрос не вышел за разрешённый каталог	Resources
проверять входные и выходные данные шаблонов	Prompts

Требование	Сила
проверять заголовок Origin во всех входящих соединениях; на недопустимый отвечать 403	обязан
при локальном запуске слушать только 127.0.0.1	следует
проверять подлинность всех соединений	следует
отклонять запрос, в котором заголовки не совпадают с телом: 400 и код -32020	обязан

Первые два пункта защищают локальный сервер от обращения с чужой веб-страницы через подмену DNS (DNS rebinding). Подробности - на странице «Транспорты».

Требование	Сила
проверять токен доступа до обработки запроса	обязан
принимать только токены, выданные именно для этого сервера	обязан
не передавать полученный от клиента токен стороннему API	не должен
на недействительный или просроченный токен отвечать 401	обязан
учитывать иерархию областей доступа при проверке	обязан

Передача токена насквозь запрещена спецификацией авторизации. В Security Best Practices объяснено почему: сервер MCP не может отличить одного клиента от другого, а журнал стороннего API показывает не того, кто на самом деле делал запрос; обходятся проверки и ограничения самого сервера MCP, а украденный токен превращает сервер в посредника для вывода данных. Если серверу нужен доступ к стороннему API, он получает для этого отдельный токен как самостоятельный клиент OAuth.

Весь порядок - на странице «Модель авторизации».

Требование	Сила
считать requestState входом, которым управляет атакующий	обязан
защищать целостность requestState, если от него зависят права, доступ или логика	обязан
не запрашивать формой пароли, ключи, токены и платёжные данные	не должен
привязывать вопрос к клиенту и пользователю	обязан
убеждаться, что ссылку из вопроса открыл тот же пользователь	обязан
не полагаться на сведения о личности пользователя, которые передал клиент, без собственной проверки	не должен

См. «Многошаговые запросы» и Elicitation.

cacheScope: "public" означает, что ответ может быть отдан другому вызывающему, даже если адрес защищён авторизацией. Сервер обязан разграничивать доступ к каждому инструменту, ресурсу и шаблону сам и не должен полагаться только на cacheScope.

Из документа Security Best Practices официальной документации.

Сессий в протоколе нет, поэтому серверы выдают явные идентификаторы, например корзины или рабочего процесса. Атака называется перехватом идентификатора состояния: посторонний узнаёт или угадывает идентификатор и действует с чужими данными.

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

Локальный сервер выполняется на машине пользователя с его правами. Документ называет три пути атаки: вредоносная команда запуска в настройке клиента, вредоносный код в самом сервере и обращение к оставленному на localhost серверу через подмену DNS.

Серверу, рассчитанному на локальный запуск, следует:

• использовать stdio, чтобы доступ был только у клиента MCP;
• если нужен HTTP - требовать токен авторизации либо использовать сокеты Unix и подобные механизмы с ограниченным доступом.

Сервер, который подключает клиентов MCP к стороннему API и выступает перед ним одним клиентом OAuth, уязвим для атаки «запутавшийся посредник» (confused deputy): злоумышленник получает код авторизации без согласия пользователя.

Такой сервер обязан получать согласие пользователя отдельно для каждого клиента, прежде чем направлять его на сторонний сервер авторизации. Это требование записано и в спецификации авторизации.

Рекомендации документа:

• начинать с минимального набора областей для чтения и обнаружения;
• запрашивать расширение точечно, когда клиент впервые выполняет привилегированную операцию;
• в ответе о нехватке прав называть точные области, а не весь перечень;
• записывать в журнал каждое расширение прав.

Частые ошибки по тому же документу: публиковать все возможные области в scopes_supported, использовать всеохватные области вроде * или full-access, считать области в токене достаточными без собственной проверки доступа.

Это практика, а не правила MCP.

• Запускать сервер с минимальными правами: отдельный пользователь, ограниченный каталог, без лишнего доступа к сети.
• Хранить секреты вне кода и не выводить их в журнал и в результаты инструментов.
• Обновлять SDK и зависимости: значительная часть известных уязвимостей исправлена в новых версиях - см. «Уязвимости и инциденты».
• Вести журнал вызовов с указанием, кто и что вызвал.
• Ограничивать размер входных данных и время выполнения.

• Модель доверия - кто за что отвечает.
• Отравление инструментов и внедрение инструкций - как содержимое сервера влияет на модель.
• HTTP-развёртывание и Docker - практическая сторона запуска.