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

> Что обязан делать сервер MCP по спецификации 2026-07-28 и официальным рекомендациям - проверка входа, токены, идентификаторы состояния, защита HTTP-адреса, локальный запуск и серверы-посредники

Страница: https://mcpdoc.ru/security/server/
Указатель сайта: https://mcpdoc.ru/llms.txt

Сервер MCP отвечает за проверку всего, что получает, за разграничение доступа и за свои секреты. Часть требований записана в спецификации словом «обязан», часть - в официальном документе Security Best Practices. На этой странице они разведены по источникам, а общие советы по эксплуатации вынесены в отдельный раздел.

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

## Требования спецификации

### Инструменты, ресурсы, шаблоны

| Сервер обязан | Где |
|---|---|
| проверять все входные данные инструмента | [Tools](https://mcpdoc.ru/protocol/tools/) |
| разграничивать доступ к инструментам | Tools |
| ограничивать частоту вызовов инструментов | Tools |
| очищать результат инструмента перед выдачей | Tools |
| проверять все адреса ресурсов | [Resources](https://mcpdoc.ru/protocol/resources/) |
| очищать пути файлов, чтобы запрос не вышел за разрешённый каталог | Resources |
| проверять входные и выходные данные шаблонов | [Prompts](https://mcpdoc.ru/protocol/prompts/) |

### HTTP

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

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

### Токены

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

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

Весь порядок - на странице [«Модель авторизации»](https://mcpdoc.ru/auth/).

### Многошаговые запросы и вопросы пользователю

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

См. [«Многошаговые запросы»](https://mcpdoc.ru/protocol/mrtr/) и [Elicitation](https://mcpdoc.ru/protocol/elicitation/).

### Кэш

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

## Официальные рекомендации

Из документа [Security Best Practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) официальной документации.

### Идентификаторы состояния

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

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

### Локальный сервер

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

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

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

### Сервер-посредник

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

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

### Области доступа

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

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

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

## Что из этого не следует

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

## Общие советы по эксплуатации

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

- Запускать сервер с минимальными правами: отдельный пользователь, ограниченный каталог, без лишнего доступа к сети.
- Хранить секреты вне кода и не выводить их в журнал и в результаты инструментов.
- Обновлять SDK и зависимости: значительная часть известных уязвимостей исправлена в новых версиях - см. [«Уязвимости и инциденты»](https://mcpdoc.ru/security/incidents/).
- Вести журнал вызовов с указанием, кто и что вызвал.
- Ограничивать размер входных данных и время выполнения.

## Что читать дальше

- [Модель доверия](https://mcpdoc.ru/security/best-practices/) - кто за что отвечает.
- [Отравление инструментов и внедрение инструкций](https://mcpdoc.ru/security/threats/) - как содержимое сервера влияет на модель.
- [HTTP-развёртывание](https://mcpdoc.ru/deployment/http-sse/) и [Docker](https://mcpdoc.ru/deployment/docker/) - практическая сторона запуска.