Какие негативные кейсы проверить при загрузке фотографии?

Что проверяют

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

Как отвечать

Сначала уточните требования: форматы, лимит размера, минимальное разрешение, откуда грузят (веб, мобильное приложение, камера). Потом идите по группам:

• формат: неподдерживаемое расширение; .exe, переименованный в .jpg (сервер должен смотреть на содержимое, а не на расширение); HEIC с iPhone, если он не поддерживается; SVG со встроенным скриптом, это путь к XSS;
• размер: файл 0 байт, ровно на лимите и на байт больше; огромное разрешение при маленьком весе, так называемая «бомба декомпрессии», которая съедает память при обработке;
• содержимое: обрезанный или битый файл, фото с поворотом в EXIF (превью должно встать правильно), EXIF с геолокацией (проверьте, вырезают ли его перед публикацией);
• имя файла: очень длинное, с кириллицей, пробелами, эмодзи, с ../ в имени;
• сеть и прерывания: обрыв посреди загрузки, медленный канал и таймаут, повторная отправка двойным кликом, уход приложения в фон;
• права и сессия: истёкший токен во время загрузки, попытка сменить аватар чужого профиля подменой id в запросе, запрет доступа к камере или галерее;
• обход клиента: тот же запрос через Postman или curl без фронтовой валидации. Лимиты обязаны проверяться на сервере.

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

Где спотыкаются

Проверяют только расширение. Переименованный исполняемый файл или HTML под видом картинки проходит, и это уже дефект безопасности.

Забывают про граничные значения и проверяют «файл на 50 МБ» вместо «лимит плюс один байт».

Не смотрят на состояние после ошибки: сообщение показалось, но в хранилище лежит мусор, а счётчик загрузок увеличился.