Sécurité des applications Kotlin : top 10 des vulnérabilités pour débutants

Sécurité des applications Kotlin : top 10 des vulnérabilités pour débutants

Kotlin est un langage de programmation moderne, activement utilisé pour le développement d'applications Android, de solutions serveur (Ktor, Spring Boot) et même de frontend (Kotlin/JS). Cependant, comme tout autre langage, Kotlin est sujet à des vulnérabilités, surtout si le développeur débute. Dans cet article, nous analyserons le top 10 des vulnérabilités des applications Kotlin que tout développeur débutant doit connaître. Nous examinerons des exemples de code et donnerons des conseils pratiques pour les corriger.

1. Ignorer la Null Safety

Kotlin est réputé pour sa gestion sécurisée des valeurs nulles (Null Safety). Cependant, les débutants utilisent souvent l'opérateur !! (not-null assertion), ce qui entraîne des NullPointerException.

// Mauvais : risque de NPE\nval name: String? = null\nprintln(name!!.length)\n\n// Bon : appel sécurisé\nprintln(name?.length ?: "Nom absent")

Recommandation : Évitez !!. Utilisez l'opérateur Elvis (?:) ou let/also.

2. Stockage non sécurisé des secrets (Hardcoded Secrets)

Stocker des clés API, des jetons et des mots de passe directement dans le code est une erreur grave. Un attaquant peut facilement les extraire du fichier APK.

// Mauvais : jeton dans le code\nval apiToken = "sk-1234567890abcdef"\n\n// Bon : utilisation de BuildConfig ou NDK\n// Dans build.gradle : buildConfigField "String", "API_TOKEN", "\\"${apiToken}\\""

Recommandation : Utilisez des variables d'environnement, BuildConfig ou un stockage sécurisé (Android Keystore).

3. Injections SQL dans Android (Room/Exposed)

Même avec un ORM (Object-Relational Mapping), une injection est possible si vous utilisez des requêtes SQL brutes avec concaténation de chaînes.

// Mauvais : vulnérable à l'injection\nval query = "SELECT * FROM users WHERE name = '$userInput'"\n\n// Bon : requête paramétrée\nval query = "SELECT * FROM users WHERE name = ?"\nval cursor = db.rawQuery(query, arrayOf(userInput))

Recommandation : Utilisez toujours des requêtes paramétrées ou des API sécurisées (Room @Query avec paramètres).

4. Journalisation non sécurisée

La journalisation de données sensibles (mots de passe, numéros de carte) en production peut entraîner une fuite d'informations.

// Mauvais : journalisation du mot de passe\nLog.d("Auth", "Mot de passe utilisateur : $password")\n\n// Bon : journalisation uniquement du fait\nLog.d("Auth", "Tentative d'authentification utilisateur")

Recommandation : Utilisez des niveaux de journalisation et des filtres. En production, désactivez Log.v et Log.d.

5. Mauvaise utilisation de SharedPreferences

SharedPreferences stocke par défaut les données dans un fichier XML sans chiffrement. Si l'appareil est rooté, les données sont accessibles à un attaquant.

// Mauvais : SharedPreferences classiques\nval prefs = context.getSharedPreferences("app_prefs", Context.MODE_PRIVATE)\n\n// Bon : 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)

Recommandation : Pour les données confidentielles, utilisez EncryptedSharedPreferences ou DataStore avec chiffrement.

6. Vulnérabilités de désérialisation (JSON/Gson/Moshi)

La désérialisation de données non fiables peut entraîner l'exécution de code arbitraire ou une fuite de mémoire.

// Mauvais : utilisation de Gson sans validation\nval user = Gson().fromJson(jsonString, User::class.java)\n\n// Bon : vali