Можно ли проверять файлы прямо в браузере: возможности и ограничения

Современные веб‑браузеры предоставляют доступ к файлам, выбранным пользователем, через API File и FileReader. Это позволяет выполнять определённые проверки непосредственно на устройстве пользователя, не отправляя файл на внешний сервер. Однако возможности таких проверок ограничены тем, что код выполняется в песочнице браузера и не имеет прямого доступа к файловой системе за пределами выбранных объектов.

Что именно можно проверить без сервера

Ниже перечислены типы проверок, которые реализуются исключительно средствами клиентского JavaScript и Web‑API.

• Проверка размера файла – сравнение свойства size объекта File с заданными пределами.
• Определение MIME‑типа и расширения – анализ свойства type и имени файла; можно дополнительно проверять «магические» байты (сигнатуры) в первых нескольких байтах файла.
• Вычисление контрольной суммы (хэш) – использование Web Crypto API для вычисления SHA‑256, SHA‑384 или SHA‑512 напрямую в браузере.
• Сравнение вычисленного хэша со списком известных хороших или плохих значений (например, белый список одобренных документов).
• Анализ метаданных изображений – чтение ширины, высоты, глубины цвета через ImageBitmap или Canvas после загрузки файла в Blob URL.
• Базовая проверка структуры PDF – чтение первых нескольких байтов на наличие заголовка %PDF- и поиск ключевых объектов (например, /Encrypt) без полной парсинга.
• Проверка архивов (ZIP, RAR) на наличие определённых файлов внутри – при использовании библиотек, скомпилированных в WebAssembly, можно просматривать центральную директорию архива.
• Сканирование на известные шаблоны вредоносного кода – некоторые антивирусные движки (например, ClamAV) были портированы в WebAssembly и могут работать с файлом в памяти браузера.

Как выглядит типичный процесс проверки

Ниже описан порядок действий, который можно реализовать на простой веб‑странице без использования серверной части.

1. Пользователь выбирает один или несколько файлов через элемент .
2. Скрипт получает объект File из события change.
3. Выполняется быстрая предварительная проверка: размер, MIME‑тип, сигнатура (первые 4‑8 байтов). Если файл не проходит этот этап, дальнейшая обработка прерывается.
4. Файл читается в ArrayBuffer с помощью FileReader.readAsArrayBuffer.
5. На полученном буфере вычисляется хэш через crypto.subtle.digest.
6. Полученный хэш сравнивается с локально хранящимся набором допустимых значений (можно хранить в IndexedDB или в виде статического массива).
7. При необходимости запускаются более тяжёлые проверки: анализ изображения через Canvas, работа с WebAssembly‑модулем антивируса, проверка структуры PDF.
8. Результат выводятся пользователю: сообщение о том, что файл прошёл проверку, предупреждение о возможной угрозе или запрос на повторный выбор файла.

Ограничения клиентской проверки

Несмотря на перечисленные возможности, существует ряд факторов, которые снижают надёжность и применимость таких проверок.

• Доступ только к выбранным файлам – скрипт не может просканировать всю файловую систему или прочитать файлы без явного действия пользователя.
• Вычислительная нагрузка – тяжёлые криптографические операции или работа с большими архивами могут заметно замедлить интерфейс, особенно на слабых устройствах.
• Ограниченность сигнатурных баз – антивирусные движки в WebAssembly обычно содержат урезанный набор сигнатур из‑за ограничений размера и времени загрузки.
• Необходимость доверия к коду – пользователь должен быть уверен, что предоставленный JavaScript не изменён вредоносным образом и не отправляет данные на сторонние серверы.
• Ложно‑положительные и ложно‑отрицательные результаты – сигнатурный подход не гарантирует обнаружение новых или полиморфных угроз; хеш‑список эффективен только против известных файлов.
• Отсутствие гарантии целостности после проверки – даже если файл прошёл все клиентские тесты, он может быть повреждён в процессе копирования или дальнейшей обработки.

Когда клиентская проверка уместна

Использование браузера для первичной проверки файлов оправдано в следующих сценариях:

• Пре‑фильтрация загружаемых пользователем аватаров или изображений в соцсетях – проверка размера, типа и размеров изображения позволяет быстро отсеять очевидно неподходящие файлы.
• Контроль загрузки шаблонов или конфигурационных файлов в корпоративных веб‑порталах – сравнение хэша с утверждённым списком помогает предотвратить случайную загрузку устаревших версий.
• Образовательные или демонстрационные инструменты, где нужно показать, как вычисляется хэш или как выглядит внутренняя структура простого формата (например, PNG).
• Системы, где передача файла на сервер нежелательна по соображениям конфиденциальности (например, работа с личными медицинскими данными в рамках внутреннего портала). В этом случае клиентская проверка служит дополнительным слоем защиты, но не заменяет серверный анализ.

Практический совет: что проверить в первую очередь

Если вам нужно решить, стоит ли реализовывать клиентскую проверку файлов в вашем проекте, начните с ответа на следующие вопросы:

• Какой тип файлов ожидается и какие атрибуты (размер, MIME‑тип, сигнатура) являются абсолютно обязательными?
• Есть ли у вас надёжный список известных хороших хэшей или сигнатур, который можно хранить локально без частого обновления?
• Насколько критична задержка интерфейса при обработке больших файлов? Возможно ли вынести тяжёлые вычисления в Web Worker, чтобы не блокировать основной поток?
• Есть ли требования к конфиденциальности, которые запрещают отправлять файл на внешний сервер даже для анализа?
• Готовы ли вы поддерживать актуальность антивирусных сигнатур или хэш‑списков, если решите использовать их?

Если ответы на первые два вопроса утвердительные, а остальные допускают компромиссы (например, можно использовать воркер для тяжёлых вычислений или ограничить размер проверяемых файлов), то клиентская проверка может стать полезным первым уровнем защиты. В противном случае рассмотрите гибридный подход: быстрая клиентская фильтрация + отправка файла на сервер для полного анализа.

Что следует помнить о безопасности

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

• Рассматривайте результат клиентской проверки как индикатор «низкого риска», а не как гарантию.
• При работе с конфиденциальными или критически важными данными всегда планируйте вторичную проверку на доверенном сервере или в изолированной среде (sandbox).
• Информируйте пользователей о том, какие именно проверки выполняются в браузере и какие ограничения у этого подхода.

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