Зарисовки на тему оформления кода HTTP-сервиса 2. Валидация данных

29 июня 2026 · infolimp.ru

Контекст и ситуация

С переходом на платформу 1С:Предприятие 8.3 и появлением механизма HTTP-сервисов (версии 2.0 в терминологии документации) разработчики получили гибкий инструмент для создания REST‑подобных API. Однако рост числа внешних обращений автоматически повышает требования к корректности передаваемых данных. Непроверенный JSON или XML способны вызвать не только ошибки времени выполнения, но и уязвимости, связанные с инъекциями или переполнением.

Валидация на стороне обработчика HTTP-сервиса — единственный способ гарантировать, что в бизнес-логику попадут только ожидаемые данные. Основные сценарии, требующие обязательной проверки:

• Обязательность полей (например, ИНН контрагента при создании документа);
• Типы данных (число, строка, дата);
• Допустимые диапазоны значений (сумма заказа не может быть отрицательной);
• Форматы (строгая маска номера телефона, email).

Важно: валидация должна выполняться на раннем этапе — сразу после разбора входящего payload. Это защищает как от логических ошибок, так и от целенаправленных атак.

Технический разбор: инструменты платформы

Для работы с JSON в 1С используются объекты ЧтениеJSON и ЗаписьJSON (появились в платформе 8.3.6). Для XML — ЧтениеXML и ЗаписьXML. Ниже приведён фрагмент, демонстрирующий чтение входящего JSON и его первичную проверку:

// В обработчике HTTP-сервиса
Процедура ОбработкаЗапроса(Запрос, Ответ) Экспорт
    Попытка
        Чтение = Новый ЧтениеJSON;
        Чтение.УстановитьСтроку(Запрос.ПолучитьТелоКакСтроку());
        СтруктураДанных = ПрочитатьJSON(Чтение);
        Чтение.Закрыть();
    Исключение
        Ответ.УстановитьКодСостояния(400);
        Ответ.УстановитьТелоИзСтроки("Некорректный JSON");
        Возврат;
    КонецПопытки;
    
    // Валидация обязательных полей
    Если Не СтруктураДанных.Свойство("Имя") Или Не ЗначениеЗаполнено(СтруктураДанных.Имя) Тогда
        Ответ.УстановитьКодСостояния(422);
        Ответ.УстановитьТелоИзСтроки("Поле 'Имя' обязательно для заполнения");
        Возврат;
    КонецЕсли;
    
    // Проверка типа
    Если ТипЗнч(СтруктураДанных.Сумма) <> Тип("Число") Тогда
        Ответ.УстановитьКодСостояния(422);
        Ответ.УстановитьТелоИзСтроки("Поле 'Сумма' должно быть числом");
        Возврат;
    КонецЕсли;
    
    // Дальнейшая бизнес-логика...
КонецПроцедуры

Сравнение методов валидации: статическая и программная

Существует два принципиальных подхода к валидации данных в HTTP-сервисах. Каждый имеет свои преимущества и ограничения.

Рекомендуется комбинировать подходы: использовать программную валидацию для критичных полей (ИНН, суммы) и упрощённую проверку схемы для остальных — например, через проверку количества и имён ключей.

Типичные ошибки при валидации

1. Игнорирование регистра ключей — JSON чувствителен к регистру, а в 1С свойства структур по умолчанию тоже регистрозависимы. Всегда сравнивайте ключи через СтрВРег() или используйте однозначное соглашение.
2. Неправильная обработка вложенных объектов — если структура содержит вложенный массив или другую структуру, проверяйте каждый уровень рекурсивно.
3. Пропуск проверки на Неопределено — при чтении JSON отсутствующий ключ даёт Неопределено, а не пустую строку. Условие ЗначениеЗаполнено не всегда корректно срабатывает на Неопределено.
4. Отсутствие лимитов по размеру входящего тела — злоумышленник может отправить гигабайт данных, что приведёт к зависанию сервера.

Ошибка №1 — «доверять входным данным без проверки». Даже если запрос приходит из доверенной внутренней сети, всегда проверяйте данные на стороне сервера.

Практическое руководство: контрольный список внедрения валидации

Чтобы внедрить валидацию в существующий HTTP-сервис, пройдите следующие шаги:

• Определите контракт — создайте структуру ожидаемого JSON (или XML) с указанием типов, обязательности, допустимых значений.
• Выберите стратегию — будете ли вы проверять всё программно или используете внешнюю схему.
• Реализуйте базовый обработчик ошибок — всегда возвращайте понятные сообщения с кодом 400 (некорректный синтаксис) или 422 (непрошёные бизнес-ограничения).
• Добавьте журналирование — фиксируйте каждое неудачное обращение с телом запроса (кроме паролей и персональных данных) для последующего анализа.
• Протестируйте граничные случаи — пустая строка, очень длинные значения, спецсимволы, вызов без тела.

Пример дополнительного блока проверки длины:

Если СтрДлина(СтруктураДанных.Комментарий) > 1024 Тогда
    Ответ.УстановитьКодСостояния(422);
    Ответ.УстановитьТелоИзСтроки("Комментарий не может превышать 1024 символа");
    Возврат;
КонецЕсли;

Что делать прямо сейчас

1. Откройте любой ваш HTTP-сервис, работающий через REST, и оцените, где отсутствует валидация входных данных.
2. Добавьте проверку хотя бы обязательных полей и типа чисел — это закроет 80% типовых проблем.
3. Создайте универсальную функцию валидации, которая принимает эталонную структуру и сравнивает её с полученной. Это сократит дублирование кода.

Помните: даже если внешняя система «гарантирует» корректность данных, ваш HTTP-сервис — последняя линия обороны. Не полагайтесь на клиента.

Заключение

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