Скрытая уязвимость: что обязан знать каждый Flutter-разработчик о безопасности в 2025

TL;DR для быстрой проверки

1. API и сеть
2. Хранение и шифрование данных
3. Аутентификация и авторизация
4. Безопасность приложения и кода
5. WebView и ввод
6. Разрешения устройства и чувствительные функции
7. Зависимости и обновления
8. Мониторинг и обнаружение угроз

Ниже — подробности и практические фрагменты, которые мы реально применяем в Инстадев на коммерческих проектах.

1) API и сеть

Секреты и ключи

1. Не хардкодим секреты в репозитории.
2. Для локальной разработки используем .env с загрузкой при старте.
3. На проде — только удалённые секреты (remote config, KMS, Vault) или инжекция через CI/CD.

Пример инициализации .env: void main() async { WidgetsFlutterBinding.ensureInitialized(); await dotenv.load(fileName: ".env"); // dev/test только локально runApp(const App()); }

Важно: .env помогает на деве, но не «прячет» ключи в релизе. Любые встроенные ресурсы можно извлечь. Критичные секреты держим вне клиента.

TLS и SSL-pinning

1. Минимум — принудительно https, запрет cleartext.
2. Лучше — certificate pinning по SHA-256 отпечатку публичного ключа.
3. При несоответствии пина — жёстко останавливаем сетевую активность и показываем экран с причиной.

Серверная часть обязана регулярно обновлять сертификаты; при ротации — готовим запасной пин.

Токены и сессии

1. Access-токен живёт коротко. Refresh-токен защищённо хранится, обновление — строго по 401/403 или явному флагу истечения.
2. Реализуем контролируемый рефреш и одноразовость refresh-токенов на бэке.
3. Анти-брутфорс с Rate-Limit на сервере. Клиентское «дросселирование» запросов допустимо как доп. мера UX/защиты.

WebSocket

1. Только wss://.
2. Авторизация заголовком или query-параметром с короткоживущим токеном.
3. Контроль переподключений, таймаутов и бэк-офф.

2) Данные и шифрование

Хранение чувствительных значений

1. Ключи, токены, идентификаторы — через flutter_secure_storage.
2. Если пишем что-то в локальную БД/файлы — шифруем содержимое на уровне приложения.

Пример службы хранения с шифрованием:class SecureStore { static const _storage = FlutterSecureStorage(); static final _aes = Encrypter(AES(Key.fromUtf8("16characterslong!"))); static final _iv = IV.fromLength(16); static Future save(String key, String value) async { final enc = _aes.encrypt(value, iv: _iv).base64; await _storage.write(key: key, value: enc); } static Future read(String key) async { final enc = await _storage.read(key: key); if (enc == null) return null; return _aes.decrypt64(enc, iv: _iv); } static Future remove(String key) => _storage.delete(key: key); static Future clear() => _storage.deleteAll(); }

Локальные БД

1. Для SQLite — используем SQLCipher (шифрование на уровне файла).
2. Ключ шифрования не храним открыто; защищаем через безопасное хранилище, ротация по событиям безопасности.

3) Аутентификация и авторизация

Базовые правила

1. Политика паролей: длина 8–12+, цифры, спецсимвол, заглавная, проверка частых паролей.
2. MFA на чувствительных операциях: пароль + одноразовый код или биометрия.
3. OAuth2/OIDC с проверкой nonce и state для Web-потоков.

Биометрия

1. local_auth как второй фактор.
2. Опционально: «быстрый вход» биометрией после первичной авторизации.

Привязка к устройству

1. Идентификатор устройства передаём на бэк и связываем с сессией, но не делаем его единственным фактором доверия.
2. Учитываем смену устройства и процедуры отвязки.

4) Приложение и код

Обфускация и ужимка

1. В релизных сборках включаем minifyEnabled true, shrinkResources true.
2. Обновляем правила ProGuard/R8, удаляем логи на проде.
3. Для Flutter — используем —obfuscate и —split-debug-info.

Контроль целостности

1. Сверка подписи приложения на Android, проверка источника установки.
2. На iOS — проверка сред выполнения, отклонение при джейлбрейке.

RASP

1. Подключаем RASP-библиотеку, чтобы:
2. ловить отладчик
3. определять рут/джейл
4. фиксировать эмулятор
5. отслеживать неофициальные сторы и попытки хука
6. На инцидент — телеметрия и безопасное завершение сессии.

5) WebView и ввод

WebView

1. Если JavaScript не нужен — отключаем.
2. Разрешаем переходы только на доверенные домены.
3. Запрещаем отладку WebView в продакшене.

XSS и инъекции

1. Санитизируем ввод, особенно если рендерим HTML.
2. Запрещаем опасные методы, если включён JS.
3. Проверяем схемы ссылок и внешний переход.

Поля ввода

1. Для чувствительных полей можно отключить копипаст, автозаполнение, буфер обмена.
2. Форматтеры для числовых полей и валидаторы длины/масок.

6) Разрешения и функции устройства

Разумные разрешения

1. Просим только то, без чего функционал не работает.
2. Пересматриваем перечень на каждом релизе.
3. Для Android — android:usesCleartextTraffic="false", сеть через networkSecurityConfig.

Защита экрана

1. Блокируем скриншоты/запись экрана на экранах с чувствительными данными (Android — FLAG_SECURE).
2. На iOS — минимизируем утечки через превью/мультизадачность.

Оверлеи и tapjacking

1. Отслеживаем системные оверлеи.
2. Блокируем взаимодействие при подозрительных индикаторах.

7) Зависимости и обновления

Контроль уязвимостей

1. Регулярно запускаем проверку устаревших пакетов (flutter pub outdated) и обновляем.
2. В CI подключаем анализ уязвимостей зависимостей (Snyk, OWASP Dependency-Check для Android-части).
3. Избегаем малоизвестных пакетов без поддержки и комьюнити.

Политика обновлений

1. Плановые минорные апдейты раз в спринт или месяц.
2. Срочные патчи — сразу после публикации критичных CVE.

8) Мониторинг и обнаружение угроз

Краш-репорты и логи

1. Crashlytics/Sentry для сборки фатальных и нефатальных ошибок.
2. Для событий безопасности — отдельные маркеры и алерты.
3. Логи без PII. Никаких токенов, паролей и полных запросов в прод-логах.

Поведенческие сигналы

1. Аномальное число неудачных входов, подозрительные регионы, массовые попытки восстановления — отправляем на антифрод/блокировку.
2. Для финансовых операций — требуем повторную проверку фактора.

Типовые ошибки, которые мы чаще всего видим

1. Хардкод секретов и «тестовых» ключей в релизе.
2. Долгоживущие access-токены без refresh и отзыва.
3. Включённый JavaScript в WebView «по умолчанию».
4. Открытые http-эндпоинты и разрешённый cleartext.
5. Отсутствие RASP и проверок среды выполнения.
6. Необновлённые зависимости с известными CVE.

Мини-чек-лист перед релизом

1. Сеть: https, pinning, обработка истёкших токенов.
2. Данные: secure storage, шифрование БД, очистка при логауте.
3. Логин: политика паролей, MFA, биометрия как доп. фактор.
4. Код: обфускация, удаление логов, проверка подписи.
5. WebView: JS off, вайтлист доменов, запрет отладки.
6. Устройство: минимум разрешений, FLAG_SECURE, защита от оверлеев.
7. Зависимости: апдейты, проверка уязвимостей.
8. Мониторинг: Crashlytics/Sentry, алерты по инцидентам.

Что делает Инстадев на проектах

1. Внедряем безопасную архитектуру сразу — это дешевле, чем «чинить безопасность в конце».
2. Настраиваем CI/CD с проверками уязвимостей и статическим анализом.
3. Подключаем RASP и сценарии реакции на угрозы.
4. Готовим «план Б» для ротации ключей и принудительных логаутов.
5. Проводим внутренний аудит и, при необходимости, внешний пентест.

Если нужно, подготовим под ваш продукт чек-лист внедрения с приоритизацией задач, оценкой трудозатрат и рисков. Это повышает шанс прохождения модерации стора и снижает операционные инциденты после релиза.