Загрузка через presigned URL

Выдавай presigned PUT URL, где каждое ограничение вшито в подпись, а не проверяется постфактум. API генерирует серверный UUID-ключ (никогда не выбираемый вызывающим), короткий срок (например, 60–300с), разрешённый Content-Type (например, image/jpeg) и максимальный Content-Length (например, 5 МБ) — всё закодировано в политике/подписи presigned URL, так что сам S3 применяет их до записи байта. Подделанный URL (не тот content-type, превышение размера, просрочка) отклоняется хранилищем с 403/SignatureDoesNotMatch, а не логикой приложения, срабатывающей после того как байты уже сохранены. Это важно, потому что webhook срабатывает после хранилища — если ограничения проверяются только там, злоумышленник уже сохранил скрипт под видом изображения. Докажи: попробуй загрузить с поддельным content-type и сверхразмерным payload и покажи, что хранилище отклоняет оба до срабатывания webhook.

Настрой бакет так, чтобы браузер грузил напрямую без байт через API-сервер — проксирование привязывает один поток обработчика на загрузку на всё время передачи (100 параллельных загрузок по 100 МБ при 10 МБ/с = 1000 поток-секунд I/O). Задай минимальную CORS-политику: точные разрешённые источники (не `*`), конкретные нужные заголовки (`Content-Type`, `x-amz-*`), короткий `Access-Control-Max-Age` для кеша preflight и разрешённый метод `PUT`. Проверь поток: браузер шлёт OPTIONS preflight, получает CORS-заголовки, затем PUTит напрямую на presigned URL. Ни один байт файла не касается API — сервер видит только presign-запрос и позже подтверждение завершения. Объясни, почему `*` на публичном бакете без кук не уязвимость, но всё равно неверно на приватном, где presigned URL несут авторизацию.

Предотврати перезапись ключей и replay-злоупотребления. Если вызывающий выбирает ключ объекта (например, username или имя файла от клиента), любой авторизованный пользователь может перезаписать файл другого, угадав ключ, и многократно PUTить на тот же ключ в пределах TTL URL, заменяя легитимный файл после того как webhook уже его подтвердил. Почини: presign-эндпоинт генерирует UUID-ключ, сохраняет запись ожидающей загрузки `{uploadId, key, expectedContentType, maxSize, createdAt, status:'pending'}`, и webhook завершения помечает только загрузку, чей UUID совпадает. Запись ожидания также хранит окно истечения, чтобы рассуждать о гонке: клиент мог загрузить корректный файл, пройти верификацию, затем повторно PUTнуть другой файл на тот же ключ до истечения URL. Смягчи, сохраняя контракт ожидаемого ETag или через короткий срок + одноразовость (инвалидируй запись ожидания при первом завершении). Задокументируй компромисс: короткий срок сужает окно гонки, но заставляет клиентов чаще пере-presign.

Проверяй получение на сервере — никогда не доверяй сообщению клиента 'я загрузил'. Webhook завершения (или клиентский POST /uploads/:id/complete) запрашивает метаданные объекта из хранилища (HEAD Object → ETag + Content-Length) и подтверждает соответствие ожидаемым значениям из контракта presign (content-type, размер в пределах max, ключ совпадает с записью ожидания). Webhook идемпотентен: повтор или дублирующая доставка (retry сети, fan-out событий S3) с тем же uploadId — no-op, а не двойная обработка. Важны два режима отказа: (1) подмена — HEAD показывает другой ETag/размер, чем ожидалось, потому что клиент повторно PUTнул другой файл в окне TTL (см. этап 3); (2) призрачное завершение — клиент сообщает о завершении, но объект не прибыл (HEAD 404). Оба отклоняются, никогда не помечаются 'получено'. Задокументируй, почему верификация ETag ломает multipart-загрузки (составной ETag из хешей частей) и что бы ты сделал там вместо этого (хранить ETag частей или перейти на checksum S3 Multipart Complete).

Докажи под прод-подобной нагрузкой и сделай наблюдаемым, когда оно ведёт себя плохо. Нагрузи полный поток (presign → прямой PUT → завершение) множеством параллельных клиентов (например, 50 параллельных загрузок, смесь валидных/невалидных, просроченные URL, сверхразмерные попытки) и найди QPS, где узким местом становится presign-эндпоинт или webhook, а не прямой PUT в хранилище. Снимай RED-метрики (rate presign, error rate presign, rate завершений, длительность верификации webhook p50/p99) и трейс-span на HEAD-верификацию, чтобы собственная латентность системы была видна в водопаде. Затем отработай инцидент: инжектируй флуд повторов просроченных URL или всплеск сверхразмерных загрузок и смотри, как взлетает error rate presign, пока прямые PUT остаются здоровыми. Обнаружь это по дашборду (не логам), смягчи (короче срок / отклонение размера на presign / rate-limit presign) и напиши пост-мортем на 5 строк, чья превенция — не 'увеличь хранилище'.