Номинируйте кейсы на Workspace Digital Awards 2026. Прием заявок до 15 декабря по льготной цене, успейте принять участие!
Назад
Мобильная разработка

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

682 
 

Коротко: большинство проблем с безопасностью в Flutter-проектах не в фреймворке, а в подходе. Если заранее не спланировать хранение секретов, сети, аутентификацию, защиту кода и телеметрию, приложение остаётся уязвимым - даже если UI и производительность отличные.

Что нужно знать про безопасность мобильных приложений
Что нужно знать про безопасность мобильных приложений

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);


Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13203 тендера
проведено за восемь лет работы нашего сайта.


  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. Проверяем схемы ссылок и внешний переход.
  4. Открытые http-эндпоинты и разрешённый cleartext.
  5. Отсутствие RASP и проверок среды выполнения.
  6. Необновлённые зависимости с известными CVE.

Поля ввода

  1. Для чувствительных полей можно отключить копипаст, автозаполнение, буфер обмена.
  2. Форматтеры для числовых полей и валидаторы длины/масок.
  3. Логи без PII. Никаких токенов, паролей и полных запросов в прод-логах.
  4. Код: обфускация, удаление логов, проверка подписи.
  5. WebView: JS off, вайтлист доменов, запрет отладки.
  6. Устройство: минимум разрешений, FLAG_SECURE, защита от оверлеев.
  7. Зависимости: апдейты, проверка уязвимостей.
  8. Мониторинг: Crashlytics/Sentry, алерты по инцидентам.

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

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

  1. Просим только то, без чего функционал не работает.
  2. Пересматриваем перечень на каждом релизе.
  3. Для Android — android:usesCleartextTraffic="false", сеть через networkSecurityConfig.
  4. Открытые http-эндпоинты и разрешённый cleartext.
  5. Отсутствие RASP и проверок среды выполнения.
  6. Необновлённые зависимости с известными CVE.

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

  1. Блокируем скриншоты/запись экрана на экранах с чувствительными данными (Android — FLAG_SECURE).
  2. На iOS — минимизируем утечки через превью/мультизадачность.
  3. Логин: политика паролей, MFA, биометрия как доп. фактор.
  4. Код: обфускация, удаление логов, проверка подписи.
  5. WebView: JS off, вайтлист доменов, запрет отладки.
  6. Устройство: минимум разрешений, FLAG_SECURE, защита от оверлеев.
  7. Зависимости: апдейты, проверка уязвимостей.
  8. Мониторинг: Crashlytics/Sentry, алерты по инцидентам.

Оверлеи и tapjacking

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

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

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

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

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

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

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

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

  1. Crashlytics/Sentry для сборки фатальных и нефатальных ошибок.
  2. Для событий безопасности — отдельные маркеры и алерты.
  3. Логи без PII. Никаких токенов, паролей и полных запросов в прод-логах.
  4. Готовим «план Б» для ротации ключей и принудительных логаутов.
  5. Проводим внутренний аудит и, при необходимости, внешний пентест.

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

  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. Проводим внутренний аудит и, при необходимости, внешний пентест.

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

Выскажите мнение
Авторизуйтесь, чтобы добавить свой комментарий.




682

Лучшие статьи

Поделиться: 0 0 0
Лайки за кейсы:  54 Подписчики:  0