Безопасность загрузки файлов в прототипах: практические меры

Что может пойти не так с загрузками в прототипе

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

Большая часть проблем исходит из упрощений в прототипах. Команды полагаются на расширение имени файла (например, .png), пропускают проверки, если файл «достаточно маленький», или загружают прямо в общий облачный бакет с широкими правами. Ещё одна частая упрощённая практика — отдавать загруженный файл прямо из того же места, где он хранится, без продуманной проверки доступа и особенностей работы браузера.

Когда загрузка сделана слабо, последствия предсказуемы:

• Перехват учётной записи (например, файл, который триггерит баг в обработке изображений/PDF)
• Утечки данных («приватная» загрузка становится публичной или пользователи могут угадывать URL)
• Большие счета за облако (большие файлы, повторные ретраи или боты, злоупотребляющие endpoint)
• Репутационные потери (вредоносный контент под вашим доменом или бакетом)

Полезная модель: у каждого флоу загрузки четыре шага — принять, проверить, сохранить, отдать.

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

Пример: в прототипе у вас кнопка «загрузить фото профиля». Злоумышленник загружает avatar.png, который на самом деле HTML или скрипт. Если вы сохраните его в публичном бакете и отдадите с неправильным Content-Type, это может выполниться в чужом браузере и украсть сессии.

Сначала установите чёткие лимиты по размеру и частоте

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

Начните с того, что действительно нужно пользователям. Если нужны только фото профиля, лимит 5–10 МБ обычно достаточен. Если вы принимаете видео или дизайнерские файлы, поставьте выше лимит сознательно и добавьте дополнительные меры.

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

• Жёсткий max‑размер на файл
• Макс общий размер на запрос (чтобы 20 «маленьких» файлов не превратились в гигантский)
• Таймауты загрузки
• Суточные лимиты на пользователя (файлы/день или суммарно МБ/день)
• Ограничения всплеска (загрузок/минуту)

Таймауты важнее, чем им дают кредит. Без них атакующий может медленно «подливать» данные и занимать рабочие потоки сервера. Если вы используете pre‑signed загрузки прямо в хранилище, ставьте короткий срок жизни, чтобы URL не использовался вечно.

Делайте сообщения об ошибках понятными, чтобы реальные пользователи могли быстро исправить проблему. Говорите, что именно произошло и каков лимит (например, «Файл слишком большой. Макс 10 МБ.»). Разделяйте «слишком много загрузок сегодня» и «загрузка прервана по таймауту», потому что это обычно разные причины.

Проверяйте реальный тип файла (а не только имя)

Имя файла вроде invoice.pdf почти ничего не говорит. Любой может переименовать invoice.exe в invoice.pdf и загрузить. Рассматривайте расширения как подсказку, а не как правило.

Браузеры также посылают MIME‑тип (например, image/png). Его стоит проверять, но не доверять — это данные, контролируемые клиентом.

Подтверждайте тип по содержимому файла

Используйте «magic bytes» (заголовок файла), чтобы определить, чем файл действительно является. У настоящего PNG есть специфическая сигнатура в начале файла. Это ловит трюки, где имя и заявленный MIME‑тип говорят одно, а содержимое — другое.

Держите правило простым: принимайте только точные типы, которые поддерживаете, и отклоняйте всё остальное. Белый список безопаснее, чем попытки блокировать «плохие» типы.

Для многих прототипов разумный стартовый белый список: image/jpeg, image/png и application/pdf. Добавляйте text/plain только при явной необходимости и аккуратно с его рендерингом.

Остерегайтесь ZIP и офисных форматов

ZIP и офисные документы (DOCX/XLSX/PPTX) более рискованы, потому что они контейнеры. В них можно спрятать скрипты, макросы или неожиданные структуры. Если вы обязаны принимать такие файлы, относитесь к ним как к «требуют доп. проверки»: жёсткие лимиты, сканирование на вредоносное ПО и запрещённая прямая отдача.

Конкретный пример: кто‑то загружает profile.png, но magic bytes показывают, что это Windows‑исполняемый файл — отвергайте и логируйте попытку.

Безопасно обрабатывайте имена файлов и пути

Многие баги с загрузкой не связаны с malware. Они связаны с доверием к именам файлов. Если приложение использует имя от пользователя для построения пути, простая загрузка может перезаписать файлы, сломать страницы или привести к утечке данных.

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

Более безопасные правила именования

Самый безопасный подход — игнорировать имя пользователя для хранения. Генерируйте серверное имя (случайный ID или UUID) и храните оригинальное имя только как текст для отображения в базе данных после очистки.

Практические правила, которые предотвращают большинство проблем с именами:

• Генерируйте собственное имя для хранения и сами выбирайте расширение
• Стривайте разделители путей (/, \\) , начальные точки и невидимые символы
• Нормализуйте Unicode, чтобы избегать похожих символов, создающих дубли
• Блокируйте двойные расширения (например, photo.jpg.exe)

Примеры ввода, против которых стоит проектировать: ../../app.env или avatar.png\u202Egnp.exe. Если сохранять такие имена напрямую, можно записать за пределами нужной папки или спрятать исполняемый файл за видом похожего имени.

Держите загрузки вне публичных путей

Никогда не храните пользовательские загрузки в публичной веб‑папке приложения. Помещайте их в приватное место (приватный бакет или приватный путь на диске), а отдавайте через контролируемую endpoint для скачивания.

Отделяйте сырые загрузки от обработанных артефактов. Храните оригинал в одном месте, а ресайзы или превью в другом — так проще управлять правами и безопасно чистить старые данные.

Сохраняйте загрузки безопасно: приватные бакеты и жёсткие права

Проще и безопаснее по умолчанию считать каждую загрузку приватной, пока не появится веская причина сделать её публичной. Большинство «прототипных утечек» происходят потому, что хранилище настроили как public‑read ради удобства и забыли это исправить.

Держите пользовательский контент отдельно от статических ресурсов приложения. Поместите пользовательский контент в один бакет, а ресурсы сайта (логотипы, CSS, сборочные файлы) — в другой. Тогда ошибка прав на загрузки не раскроет весь сайт, а пайплайн сборки не перезапишет пользовательские файлы.

Ограничьте, кто может записывать

Загружайте через небольшой серверный сервис с минимально необходимыми привилегиями. Этот сервис должен уметь записывать новые объекты и читать только то, что ему нужно. Избегайте прав на листинг всего, удаление всего или изменение политики бакета.

Стремитесь к скучным настройкам по умолчанию: приватные объекты, отдельные бакеты для dev/staging/prod, шифрование там, где поддерживается, и включённые журналы аудита для политик и доступа к объектам.

Позвольте пользователям скачивать, не делая файлы публичными

Когда пользователю нужен файл, используйте короткоживущие подписанные URL, генерируемые сервером. Это даёт временный доступ без переключения объекта в публичный режим.

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

Обрабатывайте и отдавайте файлы, не раскрывая пользователей

Загрузка — это лишь половина риска. Другая половина — что приложение делает дальше: обработка, превью и отдача.

Безопасная практика — считать каждую новую загрузку ненадёжной и помещать её в карантин до завершения проверок. Если что‑то проскочит, это не будет случайно доступно публично.

Для изображений избегайте отдачи оригинала. Изменяйте размер и перекодируйте (распакуйте изображение и запишите его заново как PNG или JPEG). Это убирает многие скрытые payload‑ы и лишние метаданные.

Для документов устанавливайте жёсткие лимиты на страницы, размер и время извлечения. PDF и офисные файлы могут быть огромными, вложенными или испорчены. Закрывайте обработку, если она занимает слишком много времени. Если нужны превью, безопаснее генерировать изображение превью, чем рендерить документ в браузере.

Никогда не рендерьте HTML или SVG от пользователя напрямую. Если вынуждены их принимать, конвертируйте в безопасный формат (например, растровое изображение) или предоставляйте для скачивания с заголовками, запрещающими inline‑выполнение.

При отдаче файлов следующие правила выполняют большую часть работы:

• Не отдавайте загрузки с основного origin приложения
• Используйте подписанные URL или endpoint‑прокси, который проверяет доступ
• Принудительно скачивание для рискованных типов и ставьте заголовки, запрещающие inline‑выполнение
• Отслеживайте статус (в карантине, одобрен, отклонён, удалён) и логируйте ключевые события (пользователь, IP, хеш, решение)

Пример: основатель загружает logo.svg для лендинга. Если рендерить его inline, он может выполниться в некоторых браузерах. Если конвертировать в PNG и отдавать только PNG, риск резко падает.

Варианты сканирования на вредоносное ПО и практические компромиссы

Сканирование на вредоносное ПО не всегда обязательно для прототипа, но быстро становится оправданным, когда загрузки делятся между пользователями, открываются командой или обрабатываются в превью. Если ваше приложение работает с выставленными счетами, резюме, ZIP, офисными файлами или любым контентом, который скачивают, сканирование — практичная часть безопасности.

Если загрузки — только изображения для аватаров, иногда можно отложить сканирование и снизить риск перекодированием изображений и отказом от всего, что не похоже на настоящее изображение. Но как только появляются реальные пользователи, сканирование — недорогая страховка.

Большинство команд выбирает один из трёх подходов: встроенное сканирование в облачном стеке, сторонний API для сканирования или self‑hosted антивирус в воркере. «Лучший» вариант — тот, который вы действительно будете поддерживать и мониторить.

Безопасный дефолт — сканировать при загрузке перед любой обработкой (thumbnail, парсинг, генерация превью) и разрешать отдачу только после отметки «clean». Если вы добавляете сканирование позже, просканируйте существующие файлы «в покое», чтобы очистить старые данные.

Когда скан даёт положительный результат, рассматривайте это как инцидент безопасности, а не ошибку UI: блокируйте доступ сразу, помещайте объект в карантин, уведомляйте владельца и команду и храните аудиторский след (пользователь, время, хеш, результат).

Пошагово: безопасный поток загрузки, который можно реализовать

Хорошая безопасность загрузок — в основном про повторяемость: выполнять одни и те же проверки в одном и том же порядке, прежде чем файл станет доступен другим пользователям.

1) Приём во временную область

Принимайте загрузки только во временное место (temp‑бакет или temp‑папка), которое никогда не является публичным.

• Применяйте ограничения «у двери»: размер, число файлов, таймауты и базовые ограничения частоты
• Считайте имя файла ненадёжным и генерируйте собственное имя для хранения
• Проверяйте реальный тип файла через magic bytes и белый список

2) Инспекция, сохранение и безопасная отдача

Прежде чем что‑то станет видимо в приложении, сканируйте и изолируйте. Если вы не можете сканировать сразу, держите приватно и ограничьте доступ.

• Сканируйте и помещайте в карантин; если скан завершился ошибкой или пометил файл, не прикрепляйте его к пользовательскому контенту
• Перемещайте одобренные файлы в приватное хранилище с жёсткими правами и понятными метаданными (владелец, назначение, created_at)
• Отдавайте через короткоживущие подписанные URL или прокси‑endpoint, который проверяет авторизацию

Настройте автоматическую очистку. Истекайте временные загрузки, которые не использовались, и удаляйте старые файлы, которые больше не нужны. Это предотвращает загадочный рост хранилища и уменьшает blast radius.

Частые ошибки, ведущие к инцидентам с публичными бакетами

Большинство инцидентов с «публичными бакетами» — не хитроумные взломы. Это небольшие удобные настройки, которые тихо становятся постоянными и потом копируются в продакшен.

Типичная ошибка — выставить бакет публичным, чтобы превью работали на демо. Другой — возвращать прямые публичные URL из API, потому что это проще, чем подписанные URL или endpoint для скачивания. Если имена предсказуемы (например, invoice.pdf), их можно перебирать. Даже если имена случайные, утёкшая ссылка становится постоянной утечкой, когда объект публичный.

Повторяющиеся красные флаги:

• SDK облака в браузере, который может писать в хранилище
• Один ключ с правами «читать/писать всё»
• Подписанные URL или токены, попадающие в логи или аналитику
• «Временные» ACL, которые копируют в продакшен

Более безопасные паттерны так же быстры:

• Храните данные приватными по умолчанию и отдавайте через подписанные URL или ваш сервер
• Загружайте в приватную «incoming» область, затем повышайте статус у одобренных файлов
• Держите креденшлы на сервере; давайте клиентам узкие, короткоживущие токены для загрузки

Быстрая чек‑листа перед релизом

Если у вас есть только один проход перед запуском, сосредоточьтесь на контролях, которые предотвращают самые дорогие ошибки.

Лимиты и валидация

• Примените жёсткий max‑размер на сервере и базовые ограничения частоты по пользователю или IP
• Проверяйте тип файла через magic bytes, а несовпадения MIME‑типа считайте подозрительными
• Перекодируйте рискованные форматы, когда это возможно, вместо отдачи оригинала

Хранение и доступ

• Храните загрузки в приватном хранилище по умолчанию с ролями наименьших привилегий
• Никогда не отсылайте ключи хранилища или секреты подписи в фронтенд код
• Если вы принимаете PDF, офисные файлы, ZIP или внешний контент, планируйте сканирование и карантин

Обратимость

• Иметь аварийный выключатель: ротировать креденшлы, отзывать токены, блокировать публичный доступ на уровне политики бакета
• Делать удаление быстрым: удалять файл и его производные и вести логи, чтобы найти пострадавших пользователей

Что делать дальше, если у вашего AI‑созданного приложения уже есть риски с загрузками

AI‑сгенерированные прототипы часто заставляют загрузки работать, но пропускают важные ограждения. Типичные симптомы: постоянные публичные URL, загрузки без логина, отсутствие max‑размера на сервере и доверие MIME‑типу от браузера без проверки содержимого.

Если вам нужно, чтобы кто‑то быстро оценил риск, полезно собрать: репозиторий (или минимальную копию с кодом загрузки и конфигурацией), настройки хранилища (public/private и правила доступа), куда идут загрузки (браузер→бакет или через сервер), несколько логов загрузок, типы файлов, которые вы допускаете, и желаемые лимиты.

Если вы унаследовали проект от инструментов вроде Lovable, Bolt, v0, Cursor или Replit, FixMyMess (fixmymess.ai) фокусируется на исправлении именно этих блокеров для продакшена: отсутствующие проверки аутентификации, слабая валидация, небезопасная обработка имён файлов, слишком широкие права облачного хранилища и отсутствие ворот карантина или сканирования. Бесплатный аудит кода часто достаточно, чтобы получить конкретный список приоритетных исправлений без догадок.