> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/nfc-wallet-sdk-android/es/security-and-privacy/security-guidance.md). # Guía de seguridad ## Resumen Utiliza esta guía de seguridad al crear y publicar una aplicación Android **aplicación de cartera digital** que integra el SDK de NFC Wallet. Esta guía es un conjunto de pautas de seguridad que debes aplicar antes de la publicación. ## Pautas generales de seguridad ### Usa la versión más reciente del SDK de NFC Wallet Usa la versión más reciente del SDK de NFC Wallet. Incluye las últimas actualizaciones y correcciones de seguridad. ### Usa la compilación de lanzamiento del SDK de NFC Wallet Antes de publicar en Google Play Store, configura la aplicación de cartera digital para usar la `Lanzamiento` compilación. {% hint style="warning" %} La `Desarrollo` La variante del SDK no está permitida en el entorno de producción. {% endhint %} ### Elimina los símbolos de depuración No publiques con símbolos de depuración. Esta práctica aumenta la complejidad de los esfuerzos de ingeniería inversa y dificulta la identificación de variables, estructuras y lógica sensibles. ### Evita filtraciones de datos sensibles Borra los datos sensibles de la interfaz antes de que la aplicación pase a segundo plano. Cifra o borra los datos hasta que la aplicación vuelva al primer plano. Evita registrar información sensible. ### Usa ofuscación de código Usa ofuscación para aumentar el coste de la ingeniería inversa. ### Comunicación de red segura Usa HTTPS para todas las llamadas de red al backend de la cartera digital. Evita certificados autofirmados. Si implementas el anclaje de certificados, sigue estas pautas: * Coincide el nombre de host con el certificado hoja. * Valida toda la cadena de certificados frente al almacén de confianza del sistema. * Rechaza los certificados caducados. * Ancla el hash SHA-256 de la CA raíz o del certificado hoja. Si envías datos confidenciales que contienen información de identificación personal (PII), añade cifrado y autenticación a nivel de aplicación cuando sea necesario. ### Añade protección RASP Usa una solución comercial de Runtime Application Self Protection ([RASP](https://en.wikipedia.org/wiki/Runtime_application_self-protection)) Detecta y responde a: * Root o jailbreak. * Depuración. * Hooking. * Manipulación de la aplicación. * Ejecución en emulador. ### Registro Evita escribir datos sensibles en los registros del dispositivo. Usa flags de compilación para excluir los registros de depuración de las compilaciones del entorno de producción. En Android, los registros son un recurso compartido al que se puede acceder con el permiso `READ_LOGS` , y el registro inadecuado de información sensible del usuario puede provocar fugas de datos no intencionadas hacia otras aplicaciones. ### Adopta prácticas de codificación segura Aplica prácticas de codificación segura durante todo el desarrollo. Por ejemplo, deberías: * realizar validación de entradas. * gestionar adecuadamente la memoria. * usar funciones C seguras. * evitar el uso de contenedores inmutables para almacenar datos sensibles. Como lista de comprobación básica, consulta OWASP [Prácticas de codificación segura](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide). Estas prácticas pueden aplicarse mediante herramientas de análisis estático de código como PMD o HP Fortify. ### Realiza auditorías y pruebas de penetración Realiza auditorías de arquitectura y código, además de pruebas de penetración, para identificar vulnerabilidades y evaluar la postura general de seguridad de la aplicación. ### Evalúa la resiliencia de la seguridad de la aplicación Consulta el estándar OWASP MASVS (Mobile Application Security Verification Standard) en [OWASP MASVS](https://github.com/OWASP/owasp-masvs). Esta es la base de requisitos de seguridad para aplicaciones móviles. Se recomienda encarecidamente usar la [lista de comprobación](https://github.com/OWASP/owasp-mastg/releases/latest) OWASP MSTG para evaluar el nivel de seguridad de tu aplicación. ## Guías de seguridad para desarrolladores de Android Usa la guía de seguridad de Android para obtener recomendaciones detalladas de defensa en profundidad antes de la publicación. Revisa estos temas: * [Protección a nivel de aplicación](#application-level-protection) * [Protección de datos](#data-protection) * [Autenticación](#authentication) * [Pautas de criptografía](#cryptography-guidelines) * [Endurecimiento de la aplicación](#application-hardening) * [Codificación segura](#secure-coding) {% hint style="info" %} Usa la lista de comprobación de seguridad base de Android como referencia adicional a esta guía: [Lista de comprobación de seguridad de Android](https://developer.android.com/training/articles/security-tips). {% endhint %} ### Protección a nivel de aplicación #### Verifica el instalador de tu aplicación Verifica en tiempo de ejecución el nombre del paquete del instalador de tu aplicación de cartera digital. Solo confía en las instalaciones desde Google Play, que usa `com.android.vending`. para evitar la distribución por canales secundarios o las instalaciones no autorizadas desde fuentes de terceros. #### Impón actualizaciones de seguridad (forzar actualización de la aplicación) Asegura una actualización forzada de la aplicación en caso de correcciones de seguridad. * Bloquea el acceso al servicio cuando la versión instalada sea inferior a la versión mínima permitida. #### Almacena los recursos en almacenamiento interno Mantén tu **aplicación de cartera digital** y sus recursos en almacenamiento interno. Esto reduce el riesgo de un ataque man-in-the-disk (MITD). En los ataques MITD, un atacante puede modificar o manipular archivos almacenados en el almacenamiento externo. La aplicación no debe permitirse moverse al almacenamiento externo usando el `atributo de manifiesto` . #### Compatibilidad con las versiones del SO admitidas por el SDK Ejecuta tu **aplicación de cartera digital** solo en versiones del SO compatibles con el SDK de NFC Wallet. Esto reduce los problemas funcionales y las brechas de seguridad en dispositivos antiguos. También mejora la **usuario final** experiencia. #### Exige una pantalla de bloqueo del dispositivo Exige que el dispositivo tenga un bloqueo de pantalla. Usa un PIN, patrón o contraseña. Bloquea los flujos sensibles si no hay ningún bloqueo de pantalla configurado. ```java KeyguardManager keyguardManager = (KeyguardManager) context.getSystemService(Context.KEYGUARD_SERVICE); boolean isDeviceSecure = keyguardManager != null && keyguardManager.isDeviceSecure(); if (!isDeviceSecure) { // Bloquea el flujo. // Solicita al usuario final que habilite un bloqueo de pantalla en Ajustes de Android. } ``` #### Evita permisos excesivos Declara solo los permisos de Android necesarios para tu **aplicación de cartera digital**. Los permisos innecesarios amplían la superficie de ataque y pueden exponer datos privilegiados. #### Restringe los componentes exportados Las aplicaciones Android se construyen a partir de componentes: * Actividades * Servicios * Receptores de broadcast * Proveedores de contenido Considera: * La comunicación entre aplicaciones como algo arriesgado. * Cada componente exportado como un punto de entrada público en tu **aplicación de cartera digital,** aumentando así su exposición a riesgos y ataques. Recomendamos diseñar tu aplicación * con solo una actividad principal accesible públicamente. * Todos los demás componentes deben tener explícitamente el atributo `export=false`. Para que los componentes sean públicos, considera protegerlos con permisos personalizados. #### Desactiva la depuración en compilaciones de lanzamiento Asegúrate de que la `release` compilación de tu **aplicación de cartera digital** no sea depurable. Debes: * Establece `android:debuggable="false"` en la `` elemento en `AndroidManifest.xml`. * Y asegúrate de que tu APK final no sea depurable. Para verificar tu APK final: 1. Ejecuta: ```bash aapt dump xmltree AndroidManifest.xml ``` 2. En la salida, localiza el `` elemento. Confirma `android:debuggable` está establecido en `0x0`. Automatiza esta verificación como parte de tu canal de CI. #### Evalúa los enlaces de aplicaciones y enlaces profundos Los enlaces profundos y los enlaces de aplicaciones pueden aumentar la superficie de ataque de la aplicación. Pueden introducir riesgos como el secuestro de enlaces y la exposición no intencionada de funcionalidad sensible. El comportamiento varía según la versión de Android: * Antes de Android 12 (nivel de API 31), si la aplicación incluye algún enlace no verificable, es posible que el sistema no verifique todos los Android App Links para esa aplicación. * A partir de Android 12 (nivel de API 31), la aplicación se beneficia de una superficie de ataque reducida. A menos que la aplicación de destino esté aprobada para el dominio específico en la intención web, la intención web se resuelve en la aplicación de navegador predeterminada del usuario final. Enumera todos los enlaces profundos. Verifica la asociación correcta con el sitio web. Prueba todas las operaciones expuestas a través de enlaces profundos y enlaces de aplicaciones. Valida siempre todos los datos de entrada. Trata todas las entradas como no confiables. La validación garantiza que la aplicación procese solo los datos que espera. #### Evita capturas de pantalla y vistas previas de la aplicación Establece `FLAG_SECURE` en cualquier actividad que muestre datos sensibles. Esto evita la fuga de datos sensibles a través de capturas de pantalla en primer plano. Añade la bandera en `Activity.onCreate()` antes de renderizar la interfaz de usuario: ```java @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); getWindow().addFlags(WindowManager.LayoutParams.FLAG_SECURE); } ``` Borra también la información sensible en tus actividades en `onPause()` método. #### Firma adecuada de la aplicación Firma tu APK de lanzamiento con: * APK Signature Scheme v1 y v2 para amplia compatibilidad con Android. * APK Signature Scheme v3 cuando apuntes a Android 9 (nivel de API 28) y posteriores. {% hint style="info" %} Mantén la clave de firma del APK bajo tu control. No la compartas. {% endhint %} Verifica las firmas con `apksigner` de Android SDK Build Tools: ```bash $ apksigner verify --verbose Desktop/example.apk Verificado usando el esquema v1 (firma JAR): true Verificado usando el esquema v2 (APK Signature Scheme v2): true Verificado usando el esquema v3 (APK Signature Scheme v3): true Número de firmantes: 1 ``` #### Evita la copia de seguridad de los datos de la aplicación Desactiva la copia de seguridad y restauración de Android para tu **aplicación de cartera digital**. Establece `android:allowBackup="false"` en la `` elemento en `AndroidManifest.xml`. ```xml ``` De forma predeterminada, `android:allowBackup` es `true`. Esto permite que el sistema operativo haga copias de seguridad y restaure los datos de la aplicación. Esto puede tener implicaciones de seguridad. La función de copia de seguridad también puede permitir que un usuario final copie los datos de la aplicación cuando la depuración USB está habilitada. Una vez exportados, los datos pueden inspeccionarse fuera del sandbox de la aplicación. #### Limita la accesibilidad en pantallas sensibles Los servicios de accesibilidad de Android pueden leer el contenido de la interfaz de usuario y activar acciones. Esto es esencial para los usuarios con discapacidades. También puede ser abusado por malware para capturar datos sensibles. Decide, para cada pantalla, si los servicios de accesibilidad deben acceder a contenido sensible. Usa las técnicas siguientes para reducir la fuga de datos a través de eventos de accesibilidad. {% hint style="warning" %} Bloquear la accesibilidad puede impedir que algunos **usuarios finales** usen tu **aplicación de cartera digital**. Aplica estos controles solo a pantallas realmente sensibles. {% endhint %} **Detecta los servicios de accesibilidad habilitados** Comprueba si algún servicio de accesibilidad está habilitado. Si es necesario, limita flujos específicos cuando los servicios estén habilitados. **Lista permitida de servicios de accesibilidad** Usa las API de Android para enumerar los servicios habilitados. Mantén una lista permitida o bloqueada según tu política de riesgo. Si un servicio no permitido está habilitado, avisa al **usuario final** o bloquea la operación. **Bloquea la accesibilidad para una vista** Puedes desactivar la accesibilidad para un subárbol de vistas. Esto evita eventos de accesibilidad de la vista y de sus hijos. ```java private void disableAccessibilityEvents(View view) { ViewCompat.setImportantForAccessibility( view, ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS ); } ``` **Evita que el texto sensible quede expuesto en los eventos de accesibilidad** De forma predeterminada, Android puede mostrar brevemente el último carácter escrito antes de ocultarlo. Esto puede exponer la entrada parcial (por ejemplo, `***1`) a los servicios de accesibilidad. Si esto no es aceptable para tu modelo de amenazas, oculta los caracteres inmediatamente. {% code expandable="true" %} ```java private fun hideLastDigit() { transformationMethod = SecureTransformationMethod() } class SecureTransformationMethod : PasswordTransformationMethod() { override fun getTransformation(source: CharSequence?, view: View?): CharSequence { if (source == null) return SecureCharSequence("") return SecureCharSequence(source) } class SecureCharSequence(private val charSequence: CharSequence) : CharSequence { override val length: Int get() = charSequence.length override fun get(index: Int): Char { return 'x' } override fun subSequence(startIndex: Int, endIndex: Int): CharSequence { return SecureCharSequence(charSequence.subSequence(startIndex, endIndex)) } } } ``` {% endcode %} #### Evita ataques de superposición Las superposiciones de Android permiten que una aplicación renderice la interfaz de usuario encima de otra. Esto puede habilitar el phishing y el robo de datos. Es una técnica común en los ataques de superposición. Ejemplo de escenario de phishing: Un atacante dibuja una superposición a pantalla completa encima de tu **aplicación de cartera digital**. La superposición suplanta una pantalla de inicio de sesión o PIN. Esto aumenta la probabilidad de robar las credenciales del usuario final. Protege las pantallas y entradas sensibles. Los ejemplos incluyen inicio de sesión, entrada de PIN y aprovisionamiento. **Android 12 (nivel de API 31) y posteriores** Llamar a `setHideOverlayWindows(true)` en las vistas sensibles. Esto bloquea las superposiciones que no son del sistema para esas vistas. **Android 2.3 (nivel de API 9) a Android 11 (nivel de API 30)** Usa el filtrado de toques en vistas sensibles. Esto ayuda a detectar toques oscurecidos por superposiciones. Usa una o más de estas opciones: * Habilita `setFilterTouchesWhenObscured(true)` en vistas sensibles. * Sobrescribe `onFilterTouchEventForSecurity()` para rechazar eventos de toque oscurecidos. * Comprueba los eventos táctiles en `onTouch()` y rechaza los eventos oscurecidos. {% hint style="warning" %} El filtrado de toques no cubre todas las técnicas de superposición. Algunas superposiciones pueden evitar reenviar eventos de toque. Considera esto como defensa en profundidad, no como una solución completa. {% endhint %} Para más detalles, consulta [Protección contra ataques de superposición de Android](https://www.guardsquare.com/blog/protecting-against-android-overlay-attacks-guardsquare). #### Usa un teclado propietario Evita teclados de terceros para entradas sensibles. Los teclados de terceros pueden capturar lo que **usuario final** escribe un Usa un teclado propietario que esté disponible solo en tu **aplicación de cartera digital**. Úsalo para PIN, códigos de acceso, contraseñas e información de identificación personal (PII). Si no puedes implementar un teclado propietario, usa un teclado PIN dedicado para la entrada de códigos de acceso. Aleatoriza la disposición de las teclas por sesión. Esto reduce el riesgo de shoulder surfing. También puede reducir el impacto de algunos malware de accesibilidad. ### Protección de datos #### Protege los datos en tránsito Usa TLS 1.2 o TLS 1.3 para todo el tráfico de red entre tu **aplicación de cartera digital** y tu **backend del emisor**. Configura tu **backend del emisor** para usar conjuntos de cifrado sólidos. Además: * Implemente **el anclaje de certificados** en tu **aplicación de cartera digital**. En Android 7.0 (nivel de API 24) y posteriores, usa [Configuración de seguridad de red](https://developer.android.com/training/articles/security-config) para anclar los dominios a los que llama tu aplicación. * Añade **cifrado y autenticación a nivel de aplicación** encima de TLS para proteger las cargas útiles sensibles (por ejemplo, información de identificación personal (PII)) entre tu **aplicación de cartera digital** y tu **backend del emisor**. #### Protege los datos almacenados Protege los datos sensibles almacenados en el dispositivo, incluso dentro del sandbox de la aplicación. Supón que un dispositivo comprometido puede exponer el almacenamiento local al malware. Se recomienda cifrar y proteger la integridad de los datos sensibles en reposo, usando claves vinculadas al dispositivo, y exigir autenticación del usuario final antes del acceso. Para cifrar todos los datos sensibles en reposo, la aplicación puede usar * AndroidX Security Crypto `EncryptedSharedPreferences` para datos de clave-valor. * AndroidX Security Crypto `EncryptedFile` para archivos. Para más detalles, consulta la guía de Android sobre [almacenamiento de datos](https://developer.android.com/topic/security/data). ### Autenticación #### Compatibilidad con autenticación biométrica La **aplicación de cartera digital** debe admitir la autenticación biométrica para la autenticación del usuario final. Proporciona una alternativa con credenciales del dispositivo (keyguard) cuando la biometría no esté disponible. Usa Android Keystore con `BiometricPrompt` objetos criptográficos cuando sea posible. Esto vincula las claves al dispositivo y detecta cambios en el registro biométrico. #### Impón la autenticación multifactor Impón la autenticación multifactor (MFA) para las operaciones sensibles en tu **aplicación de cartera digital**. MFA añade protección al exigir más de un factor de autenticación antes del acceso. Esto reduce el riesgo de acceso no autorizado si uno de los factores se ve comprometido. ### Pautas de criptografía #### Mantén actualizado el proveedor de seguridad de Google Play Use el [proveedor de seguridad de Google Play Services](https://developer.android.com/training/articles/security-gms-provider) para recibir correcciones de criptografía y TLS en dispositivos que no reciben actualizaciones del SO a tiempo. El SDK de NFC Wallet no instala, actualiza ni solicita este proveedor. Tu **aplicación de cartera digital** es responsable de garantizar que el proveedor de seguridad de Google Play Services esté instalado y actualizado en el **dispositivo del** usuario final. #### Usa un generador aleatorio seguro Use `java.security.SecureRandom` para toda la aleatoriedad sensible a la seguridad (generar cualquier clave criptográfica sensible o cualquier generación de datos aleatorios). En Android 10 (nivel de API 29) y posteriores, prefiere `SecureRandom.getInstanceStrong()` cuando necesites la fuente de aleatoriedad más fuerte disponible. ### Endurecimiento de la aplicación #### Detecta dispositivos con root Detecta un entorno de dispositivo comprometido (por ejemplo, frameworks de rooting y `su` binarios) antes de inicializar el SDK de NFC Wallet y antes de realizar cualquier operación sensible. Consulta la guía OWASP MSTG sobre [Defensas antiingeniería inversa en Android](https://github.com/OWASP/mastg/blob/master/Document/0x05j-Testing-Resiliency-Against-Reverse-Engineering.md). #### Detecta intentos de hooking Hooking inyecta código en tu **aplicación de cartera digital** en tiempo de ejecución. Los atacantes lo usan para interceptar datos sensibles (por ejemplo, claves criptográficas o PII), eludir controles de seguridad o cambiar la lógica de la aplicación. Consulta OWASP MASVS: [Defensas antiingeniería inversa en Android](https://mas.owasp.org/MASTG/0x05j-Testing-Resiliency-Against-Reverse-Engineering/) / *Verificación de integridad en tiempo de ejecución***.** #### Detectar la conexión de un depurador En dispositivos comprometidos, un atacante puede adjuntar un depurador a un `Lanzamiento` compilación de tu **aplicación de cartera digital**. Esto permite la inspección paso a paso del código Java/Kotlin y de las bibliotecas nativas, y puede exponer lógica y datos sensibles. Detecta la conexión de un depurador tanto en Java/Kotlin como en código nativo, especialmente antes de ejecutar flujos sensibles. Para obtener más información. Consulta OWASP MASVS: [Defensas antiingeniería inversa en Android](https://mas.owasp.org/MASTG/0x05j-Testing-Resiliency-Against-Reverse-Engineering/) / *Antidepuración*. #### Detectar emulador Los emuladores son un entorno de ejecución no confiable. Facilitan a los atacantes el análisis dinámico y la instrumentación. Detecta la ejecución en emulador lo antes posible. Hazlo al iniciar la aplicación y antes de inicializar el SDK de NFC Wallet. Consulta OWASP MASVS: [Defensas antiingeniería inversa en Android](https://mas.owasp.org/MASTG/0x05j-Testing-Resiliency-Against-Reverse-Engineering/) / *Detección de emulador.* #### Detectar manipulación de la aplicación Detecta la manipulación verificando la **aplicación de cartera digital** huella hash del certificado de firma en tiempo de ejecución. Esta comprobación ayuda a detectar ataques de reempaquetado en los que un atacante modifica el binario o los recursos y luego vuelve a firmar el APK. Los atacantes no pueden reproducir tu certificado de firma. Ofusca la huella hash del certificado esperada para que sea más difícil localizarla y parchearla. Para más información, consulta [Implementar técnicas antimanipulación](https://github.com/nowsecure/secure-mobile-development/blob/master/en/coding-practices/anti-tamper-techniques.md). Opcionalmente, envía la huella hash del certificado de firma a tu **backend**. Verifícalo del lado del servidor antes de atender solicitudes desde el **aplicación de cartera digital**. #### Ofuscar la aplicación Ofusca tu **aplicación de cartera digital** y sus componentes. Esto aumenta el costo de la ingeniería inversa. También dificulta localizar la lógica y los datos sensibles. Incluso si el SDK de NFC Wallet ya está ofuscado con DexGuard, debes ofuscar las API públicas del SDK de NFC Wallet de Thales: * Asegúrate de que se apliquen las reglas de ProGuard/R8 proporcionadas con los paquetes del SDK. Consulte [Ofuscación del SDK de NFC Wallet](/nfc-wallet-sdk-android/es/security-and-privacy/nfc-wallet-sdk-obfuscation.md) * Presta especial atención a la regla de aplanamiento de paquetes: ```bash -flattenpackagehierarchy util ``` Usa el nombre de paquete `util` para mantener la salida de la ofuscación coherente con las reglas del SDK. Existen herramientas comerciales de ofuscación. En Android, recomendamos *DexGuard*. Consulta OWASP MASVS: [Defensas antiingeniería inversa en Android](https://mas.owasp.org/MASTG/0x05j-Testing-Resiliency-Against-Reverse-Engineering/) / *Ofuscación*. ### Codificación segura #### **Borrar datos sensibles de la memoria** Almacena los datos sensibles (por ejemplo, claves criptográficas e información de identificación personal (PII)) en matrices de bytes. En Java, no puedes borrar de forma fiable objetos inmutables como `String` y `StringBuilder`. Tampoco puedes controlar cuántas copias se crean en la memoria ni cuánto tiempo permanecen accesibles. Borra explícitamente los datos sensibles. No confíes en el recolector de basura. Usa un `finally` bloque para borrar los búferes sensibles, incluso cuando no tengas un `catch` bloque. Esto reduce el riesgo de filtraciones si ocurre una excepción. {% code expandable="true" %} ```java byte[] password = this.getUserPassword(); try { // Usar la contraseña para iniciar sesión this.logUserIn(password); } finally { // Aunque aquí no haya captura de excepciones, puede existir una //RuntimeException que igualmente debería activar este bloque finally // para que se ejecute MemoryHelper.clearData(password); } //Una forma de implementar un método de borrado de un array de bytes es reescribir cada elemento de los arrays en el MemoryHelper class public static void clearData(byte[] baBuffer) { if (baBuffer == null) return; for(i = 0; i < baBuffer.length; i++) { baBuffer[i] = (byte)0; } } ``` {% endcode %} #### Sigue estándares de codificación segura Sigue estándares de codificación segura de fuentes confiables como Apple, Google y OWASP (Open Web Application Security Project). Si necesitas orientación interna de Thales, ponte en contacto con la comunidad Thales Handset Security para solicitar acceso. Haz cumplir estos estándares con herramientas de análisis estático de código como PMD o Fortify. Añádelas a tu canal de CI para evitar regresiones. #### Ejecutar comprobaciones de lint de Android Ejecuta Android Lint durante el desarrollo y antes de cada lanzamiento. Corrige los hallazgos pronto para reducir el riesgo de seguridad y calidad. Android Lint es una herramienta de análisis estático. Revisa tu proyecto en busca de problemas de corrección, seguridad, rendimiento, usabilidad, accesibilidad e internacionalización. Ejecuta lint localmente y en tu canal de CI: ```bash ./gradlew lint ``` Para obtener más detalles, consulta el sitio web para desarrolladores de Android: [Mejora tu código con comprobaciones de lint](https://developer.android.com/studio/write/lint). ## Proteger activos Esta sección describe las mejores prácticas en el desarrollo de aplicaciones para proteger los activos. ### **Código de activación** Úsalo en la tokenización de tarjetas con un ciclo de vida limitado en el tiempo: * Trátalo como un secreto de corta duración. No lo registres ni lo almacenes ### Token de registro de FCM Si la aplicación de cartera digital gestiona FCM a nivel de la app: * Evita conservar el token de registro de FCM más tiempo del necesario. ### **Información de la tarjeta de financiación** Si la aplicación de cartera digital recopila datos de tarjetas de pago: * Deshabilita opciones riesgosas `EditField` como autocompletar, copiar, pegar, etc. * Usa un teclado seguro. * Valida las entradas antes de usarlas. * No almacenes de forma persistente los datos de tarjetas de pago. * Antes de mostrar la pantalla de entrada, impón comprobaciones en tiempo de ejecución (detección de rooting, hooking, depuración y manipulación). * Garantiza la confidencialidad e integridad de este activo. Aplica los mismos controles a cualquier otra entrada sensible procedente de fuera de la app. ### Certificado de firma de la app y certificado TLS * Controla el acceso al certificado de firma de la app. * No lo reveles a partes no confiables. * Garantiza la confidencialidad e integridad de este activo. ### **Datos de entrada de QR / DSRP (importe)** Cuando la aplicación de cartera digital recopile el importe: * Deshabilita opciones riesgosas `EditField` como autocompletar, copiar, pegar, etc. * Usa un teclado seguro. Aplica los mismos controles a cualquier otra entrada sensible procedente de fuera de la app. ### Código QR (código de barras 2D) La aplicación debe implementarse para detectar y evitar la captura del código QR en capturas de pantalla o su visualización en pantallas no seguras. ### Otros activos sensibles * Ofusca el código y protege las cadenas sensibles incluidas en el binario. * Vuelve a evaluar los activos en cada lanzamiento (las nuevas funciones podrían añadir nuevos datos sensibles). * Evalúa el valor y la criticidad de cada activo y aplica la protección requerida. * No conserves datos transitorios. Borra los datos sensibles de la memoria cuando ya no sean necesarios. * Considera siempre que el dispositivo no es confiable. Usa RASP para ayudar a proteger el binario de la aplicación y las bibliotecas de terceros en tiempo de ejecución. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.payments.thalescloud.io/nfc-wallet-sdk-android/es/security-and-privacy/security-guidance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.