Seguridad de aplicaciones Kotlin: top 10 vulnerabilidades para principiantes

Seguridad de aplicaciones Kotlin: top 10 vulnerabilidades para principiantes

Kotlin es un lenguaje de programación moderno que se utiliza activamente para el desarrollo de aplicaciones Android, soluciones de servidor (Ktor, Spring Boot) e incluso frontend (Kotlin/JS). Sin embargo, como cualquier otro lenguaje, Kotlin es susceptible a vulnerabilidades, especialmente si el desarrollador recién comienza su camino. En este artículo analizaremos el top 10 de vulnerabilidades de aplicaciones Kotlin que todo desarrollador principiante debe conocer. Veremos ejemplos de código y daremos consejos prácticos para solucionarlas.

1. Ignorar Null Safety

Kotlin es famoso por su manejo seguro de valores nulos (Null Safety). Sin embargo, los principiantes suelen usar el operador !! (not-null assertion), lo que provoca NullPointerException.

// Mal: riesgo de NPE\nval name: String? = null\nprintln(name!!.length)\n\n// Bien: llamada segura\nprintln(name?.length ?: "Nombre ausente")

Recomendación: Evite !!. Use el operador Elvis (?:) o let/also.

2. Almacenamiento inseguro de secretos (Hardcoded Secrets)

Almacenar claves API, tokens y contraseñas directamente en el código es un grave error. Un atacante puede extraerlos fácilmente del archivo APK.

// Mal: token en el código\nval apiToken = "sk-1234567890abcdef"\n\n// Bien: uso de BuildConfig o NDK\n// En build.gradle: buildConfigField "String", "API_TOKEN", "\\"${apiToken}\\""

Recomendación: Use variables de entorno, BuildConfig o almacenamiento seguro (Android Keystore).

3. Inyecciones SQL en Android (Room/Exposed)

Incluso con ORM (Object-Relational Mapping) se puede permitir una inyección si se usan consultas SQL sin procesar con concatenación de cadenas.

// Mal: vulnerable a inyección\nval query = "SELECT * FROM users WHERE name = '$userInput'"\n\n// Bien: consulta parametrizada\nval query = "SELECT * FROM users WHERE name = ?"\nval cursor = db.rawQuery(query, arrayOf(userInput))

Recomendación: Use siempre consultas parametrizadas o APIs seguras (Room @Query con parámetros).

4. Registro inseguro (logging)

Registrar datos sensibles (contraseñas, números de tarjeta) en producción puede provocar una fuga de información.

// Mal: registro de contraseña\nLog.d("Auth", "User password: $password")\n\n// Bien: registro solo del hecho\nLog.d("Auth", "User authentication attempt")

Recomendación: Use niveles de registro y filtros. En producción, desactive Log.v y Log.d.

5. Uso incorrecto de SharedPreferences

SharedPreferences por defecto almacena datos en un archivo XML sin cifrado. Si el dispositivo está rooteado, los datos están disponibles para un atacante.

// Mal: SharedPreferences normales\nval prefs = context.getSharedPreferences("app_prefs", Context.MODE_PRIVATE)\n\n// Bien: EncryptedSharedPreferences (AndroidX Security)\nval masterKey = MasterKey.Builder(context)\n    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)\n    .build()\nval encryptedPrefs = EncryptedSharedPreferences.create(\n    context, "secure_prefs", masterKey,\n    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,\n    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM\n)

Recomendación: Para datos confidenciales, use EncryptedSharedPreferences o DataStore con cifrado.

6. Vulnerabilidades en deserialización (JSON/Gson/Moshi)

Al deserializar datos no confiables, se puede obtener ejecución de código arbitrario o fuga de memoria.

// Mal: uso de Gson sin validación\nval user = Gson().fromJson(jsonString, User::class.java)\n\n// Bien: vali