Saltar a contenido

Lista de verificación de seguridad de aplicaciones Flutter

Fase 0: Gobernanza, entorno y CI/CD

Aplicar puertas en CI

  • Ejecutar comprobaciones estáticas (SAST) en cada PR: flutter analyze, pruebas unitarias/UI, dart pub outdated.
  • Bloquear el lanzamiento (release) ante hallazgos de severidad Alta/Crítica en SAST/SCA/DAST; exigir cero errores de linter en las ramas de lanzamiento.

Manejo de secretos

  • Ningún secreto en el código fuente de Dart, pubspec.yaml, código nativo o en los registros (logs).
  • Usar variables de entorno (por ejemplo, --dart-define) para inyectar configuraciones en tiempo de compilación (build-time).
  • Redactar secretos en las analíticas (analytics).
  • Rotar claves/tokens de forma periódica y ante sospechas de fuga.

Evidencia y trazabilidad

  • Archivar los informes de escaneo, el SBOM, los registros de compilación y las notas de la versión con cada artefacto.

Scanning automation

  • Integrar una plataforma móvil de SAST/DAST/SCA (que soporte Flutter) en el CI/CD para que se ejecute en cada PR y pre-lanzamiento, y fallar automáticamente las comprobaciones (gates) ante problemas de severidad Alta/Crítica.

Fase 1: Modelado de amenazas, clasificación de datos e inventario

  • Clasificar los datos (PII, credenciales, tokens, datos de pago) y mapear su recolección, procesamiento, almacenamiento (archivos, bases de datos seguras) y transmisión.
  • Identificar los límites de confianza (trust boundaries): entorno Dart/Isolates, MethodChannels, bibliotecas nativas, plugins, APIs del backend.
  • Hacer un inventario de los paquetes de terceros en pub.dev; preferir plugins bien mantenidos, de editores verificados (verified publishers) y que sigan el principio de mínimo privilegio.
  • Reducir al mínimo la superficie de ataque derivada de los paquetes Dart.

Phase 2: Build and configuration hardening

Release settings

  • Asegurarse de que todas las compilaciones de producción se compilen en modo release (flutter build apk/ios --release) con AOT habilitado.
  • Eliminar los endpoints de desarrollo y las banderas de características (feature flags) de las compilaciones de producción.

Android specific

  • Usar minifyEnabled true y shrinkResources true en Gradle.
  • Declarar solo los permisos necesarios en AndroidManifest.xml.
  • Desactivar el tráfico en texto claro (cleartext traffic) en networkSecurityConfig.

iOS specific

  • Eliminar (strip) los símbolos de depuración y el código muerto.
  • Otorgar únicamente los entitlements necesarios.
  • Establecer NSAllowsArbitraryLoads = false en Info.plist.

Phase 3: Local storage and secure storage

Almacenamiento seguro

  • Usar el plugin flutter_secure_storage (o su equivalente) para todos los tokens, PII sensible y claves criptográficas.
  • Android: Asegurarse de que el plugin utilice el cifrado respaldado por Keystore (EncryptedSharedPreferences).
  • iOS: Asegurarse de que el plugin utilice el Keychain con las configuraciones de accesibilidad adecuadas (por ejemplo, kSecAttrAccessibleWhenUnlockedThisDeviceOnly).

Files and databases

  • Evitar el almacenamiento de secretos o PII sensible en texto plano dentro de SharedPreferences o archivos locales.
  • Cifrar bases de datos (por ejemplo, sqflite con SQLCipher) si almacenan información sensible.
  • No registrar (log) secretos, ni siquiera de manera temporal.

Caches and derived data

  • Evitar la persistencia de PII en cachés/directorios temporales.
  • Purgar los cachés/directorios temporales al cerrar la sesión.

Phase 4: Privacy safeguards (UI, clipboard, screenshots)

  • Ocultar la UI sensible en la vista de aplicaciones recientes (app switcher) (por ejemplo, usando el plugin secure_application o código nativo para desenfocar/ocultar la pantalla).
  • Evitar la lectura del portapapeles en el inicio de la aplicación.
  • Nunca depositar contraseñas, claves o tokens de larga duración en el portapapeles del sistema.

Phase 5: Network security and TLS/pinning

Aplicación de HTTPS/TLS

  • Exigir HTTPS en todas las comunicaciones de la aplicación. El cliente HTTP predeterminado de Dart exige TLS, pero debe configurarse de tal forma que rechace los certificados inválidos.
  • Nunca eludir las comprobaciones de certificados en entornos de producción (badCertificateCallback).

Certificate pinning

  • Implementar el fijado de certificados (certificate pinning) SSL/TLS (por ejemplo, comprobando el SHA-256 en el objeto SecurityContext).
  • Validar la resistencia contra escenarios de ataque MITM y certificados hojas (leaf) rotados o expirados.
  • Planificar la rotación segura de los pines y prever opciones de respaldo (fallbacks).

Cookies and tokens

  • Evitar almacenar tokens portadores (bearer tokens) de larga duración en el dispositivo.

Fase 6: Autenticación, autorización y sesión

Flujos de autenticación

  • Utilizar OAuth2/OIDC junto a PKCE para flujos públicos de autenticación (por ejemplo, mediante flutter_appauth).
  • Nunca integrar secretos de cliente (client secrets) o claves API asociadas a autenticación en el código fuente de Dart.
  • Preferir los componentes del navegador del sistema (Chrome Custom Tabs, SafariViewController) antes que usar una WebView integrada en la aplicación para iniciar sesión.

Tokens

  • Utilizar tokens de acceso de corta duración.
  • Almacenar de forma segura los tokens de actualización (refresh tokens) (por ejemplo, mediante flutter_secure_storage).
  • Rotar e invalidar los tokens al cerrar la sesión, al cambiar de dispositivo o si se registran actividades sospechosas.

Autorización

  • Exigir la validación de autorización en el lado del servidor; el estado de la aplicación Flutter siempre debe considerarse como no confiable (untrusted).
  • Implementar Android App Links y iOS Universal Links preferentemente por sobre el uso de esquemas de URL personalizados.
  • Validar desde el código Dart el origen de todos los enlaces entrantes, así como también sus parámetros.

Custom schemes and intents

  • Si es necesario usar esquemas personalizados, debe cerciorarse de someter cualquier dato y su tipo proveniente del exterior a un fuerte proceso de validación.
  • Generar defensas frente al secuestro de URLs (URL hijacking) y contra métodos de desvío de navegación (open redirects).

Phase 8: Reverse engineering and tamper resilience

Code obfuscation

  • Asegurarse de que el compilado en modo release en Flutter construya sobre los lenguajes nativos valiéndose de su característica AOT.
  • Emplear las capacidades de compilación en Flutter para lograr la ofuscación de la información de clases o elementos en su código de negocios (flutter build apk --obfuscate --split-debug-info=/<dir>).

Verificaciones de entorno

  • Determinar la eventualidad de ejecución en entornos no permitidos o vulnerables tales como jailbreak o root mediante componentes conocidos y seguros (tales como flutter_jailbreak_detection, freerasp).
  • En base a un riesgo dictaminado, establecer medidas cautelares o acciones a implementar tales como límites funcionales, anuncios directos, o su eventual cerrado preventivo.

Anti-tamper

  • Asistirse en controles íntegros en los respectivos ecosistemas del sistema (uso del API Play Integrity sobre su equivalente Android, o DeviceCheck/App Attest para el ecosistema asociado de iOS) de manera tal que el servidor pueda validar remotamente al componente y dispositivo del usuario de forma asertiva.
  • Todo control de cliente debe estimarse como simples y meros indicios frente al control del servidor u otro dispositivo, y nunca emplearse de facto como control fundamental.

Phase 9: Cryptography and randomness

  • Usar librerías revisadas o avaladas (crypto o pointycastle) y delegar sobre primitivas construidas en nativo conectadas a la aplicación mediante los pertinentes MethodChannels.
  • Realizar empleos del generador nativo proporcionado y debidamente validado (Random.secure()).
  • Efectuar empleos mediante la construcción de componentes criptográficos apoyados sobre estándares confiables de industria (tales como componentes del protocolo bajo su especificación de la norma técnica AES-GCM).
  • Abstraerse por completo del empleo o re-utilizaciones perjudiciales (tales como re-uso IVs, claves no pre-compartidas o generadas al unísono de modo perjudicial embebidas textualmente).

Phase 10: Permissions, notifications, and identifiers

Privacy‑related permissions

  • Emplear peticiones para usos que deban realizarse limitándolos al uso concreto al que pertenezcan (petición requerida), aportando mensajes informativos con asertividad frente a lo aportado hacia su empleo en base al entorno generado.
  • Ajustar lo menor posible las necesidades limitadas y su correspondiente relación base frente a dispositivos provistos dentro o fuera de ecosistemas referidos (ubicaciones de entorno general y geoposicionado, sensores gráficos, acceso general al disco de memoria de componentes o capturas acústicas ambientales y telefónicas).

Identifiers

  • Emplear recursos limitados sobre la necesidad generada omitiendo vinculaciones persistentes a registros asociados sobre su control a elementos (evítese registros únicos atados a identificadores referidos y re-use elementos restablecidos limitados sobre ambientes internos u ocultos de base controlados localmente frente al ambiente).

Notificaciones

  • Elimine la exposición desmesurada dentro de informaciones contenidas o visualmente limitadas correspondientes al ambiente interno que sean asociadas e interceptables sobre controles emitidos local y externamente en información base; fomente elementos internos basados al entorno a buscar de su descarga referenciada en inicio del programa sobre eventos visuales o referenciados a acciones manuales en peticiones (fetch-on-open).

Phase 11: Logging, analytics, and crash reporting

Higiene de registros

  • Emplee recursos omitiendo empleos a opciones expuestas (print()) generados y localizados a base sobre desarrollos en producción, utilice ambientes en producciones debidamente delimitados mediante condicionales (kReleaseMode/kDebugMode).
  • Controle implementaciones base a recursos de registro sobre PII y/u otros tipos, referenciados a información confidencial generada sobre fallos recolectados correspondientemente (eventos en analíticas o Firebase Crashlytics y Sentry).
  • Gestione con sumo interés y eficacia componentes que ofuscan variables o información correspondientes (--split-debug-info), estos deben quedar estrictamente salvaguardados al uso remoto, limitándolos al extremo para que solo resuelvan funciones mediante servidores provistos, evitando a su vez cualquier posible exportación, exposición o relación general en producción.

Phase 12: Testing, DAST, and runtime verification

Interception tests

  • Compruebe mecanismos pertinentes referenciados e inducidos por intercepciones controlables (MITM), corroborando su limitación en comunicaciones basadas sobre validaciones locales provistas sobre configuraciones personalizadas referidas bajo Dart.

Pruebas de abuso de API

  • Recree y evalúe situaciones referidas de uso o empleo que no corresponden a límites propuestos (Rate limiting) y genere vulnerabilidades a elementos sobre (BOLA o su versión y denominativo derivado de uso hacia bases referenciadas (IDOR)), previniendo validaciones o controles y empleos asertivos generados.

Dynamic analysis

  • Desarrolle métodos basados hacia uso correspondiente generados mediante opciones de seguridad implementables evaluando información local expuesta (como DAST sobre cliente HTTP base Dart) sobre comunicaciones e interceptaciones sobre configuraciones y controles en uso erróneamente administrados de uso y ejecución generalizada a exposiciones internas u otras limitadas.
  • Exporte reportes e informaciones detalladas base de pruebas DAST y evalué priorizando o generando triajes en función sobre re-test.

Phase 13: SBOM, and evidence

SBOM y dependencias

  • Evalúe a modo base informaciones publicadas controlando componentes o versiones base provistas correspondientes (análisis y reporte generados sobre Dart u otros de índole componentes dependientes y/o sub-proyectos generados en recursos externos hacia build.gradle o Podfile).
  • Determine la recolección, administración o creación del registro (SBOM) generados a modo base frente a proyectos provistos (Flutter/Dart).

Paquete de evidencia

  • Genere evidencia e integre información provista y referida a (SAST/DAST) en reportes finales correspondientes a expedientes formados y creados sobre uso productivos de liberaciones (release).
  • Adjunte su evaluación o correspondientes registros formados y relacionados a documentos formados SBOM.

Referencia rápida para profesionales

  • Config: AOT compila para la liberación de uso, control y mitigación base de recursos kReleaseMode o de validación general con uso provisto u opciones como --obfuscate.
  • Data: Generar uso base de manera continua u otros referenciados nativamente basados a opciones asertivas generados con componentes como (flutter_secure_storage); descartando recursos expuestos a lecturas planas de recursos PII o similares referenciados (SharedPreferences u SQLfite).
  • Network: Impóngase e impulse el manejo asertivo o controlado mediante mecanismos referenciales controlados a base HTTPS; impóngase e impulse certificados validos fijados (SecurityContext) y limite a control interno de variables como validaciones y rechazos controlables referenciales (badCertificateCallback frente a su empleo general base en usos sobre producción controlada).
  • Auth: Privilegie componentes predeterminados basados a flutter_appauth junto a usos integrados sobre validaciones asociables a OAuth y/o asociables al uso mediante PKCE, desmintiendo o eliminando y privando a recursos correspondientes de poseer textualmente recursos en crudo (base secret key u análogos referenciados).
  • Tamper: Privilegie componentes predeterminados basados u otras herramientas base validadas localmente o externamente validando e inspeccionando escenarios comprometidos basados a Root/Jailbreak correspondientes (tales casos provistos u referidos como herramientas de DeviceCheck y atestados validados remotamente mediante el sistema Play Integrity o afín).
  • Privacy: Implemente y fomente elementos en validaciones controlables a usos ocultos provistos sobre escenarios transitorios entre recursos u aplicaciones y su equivalente captura correspondiente basada a ocultaciones (snapshot u similares) limitando acciones derivadas basadas u relacionadas al recolector de copia de información (clipboard o portapapeles), generando opciones o referenciales de permisos oportunos en tiempo preciso limitable de acuerdo al caso expuesto (JIT limitadas).
  • Dart/Flutter: Considere ambientes expuestos generados como recursos en base u opción referencial, evadiendo decisiones propias correspondientemente atadas al proceso general de validación externa, referenciando peticiones asertivas a uso comprobatorio; privilegie la construcción basada a un listado acotado de componentes sobre (pub.dev) con componentes estipulados y analizados correctamente.