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 créer des applications Android, des solutions serveur et des projets multiplateformes. Cependant, même avec son typage strict et sa sécurité par défaut, les développeurs débutants commettent souvent des erreurs qui peuvent entraîner de graves vulnérabilités. Dans cet article, nous allons passer en revue le top 10 des problèmes de sécurité les plus courants dans les applications Kotlin, montrer des exemples de code dangereux et donner des recommandations pour les résoudre.

1. Injections SQL (SQL Injection)

L'une des vulnérabilités les plus anciennes et les plus dangereuses. Si vous concaténez directement une entrée utilisateur dans une requête SQL, un attaquant peut exécuter des commandes arbitraires.

// DANGEREUX : concaténation de chaînesval query = "SELECT * FROM users WHERE name = '$userInput'"statement.executeQuery(query)

// SÉCURISÉ : utilisation de requêtes paramétréesval query = "SELECT * FROM users WHERE name = ?"val preparedStatement = connection.prepareStatement(query)preparedStatement.setString(1, userInput)preparedStatement.executeQuery()

2. Stockage non sécurisé des mots de passe

Ne stockez jamais les mots de passe en clair. Utilisez bcrypt, Argon2 ou PBKDF2. En Kotlin, vous pouvez utiliser la bibliothèque spring-security-crypto ou kotlinx-serialization avec hachage.

// DANGEREUX : stockage en texte clairdata class User(val password: String)

// SÉCURISÉ : hachage avec selimport org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder

val encoder = BCryptPasswordEncoder()val hashedPassword = encoder.encode(plainPassword)

3. Absence de validation des entrées (Input Validation)

Toutes les données provenant de l'utilisateur doivent être validées. Ignorer cette règle conduit à des attaques XSS, des injections et des attaques DoS.

// DANGEREUX : sortie directe sans échappementfun renderHtml(userInput: String): String {    return "<div>$userInput</div>"}

// SÉCURISÉ : échappement HTMLimport org.owasp.encoder.Encode

fun renderSafeHtml(userInput: String): String {    return "<div>${Encode.forHtml(userInput)}</div>"}

4. Vulnérabilités dans la sérialisation des données

Kotlin utilise kotlinx.serialization ou Gson/Moshi. Une configuration incorrecte peut entraîner la divulgation de données sensibles ou l'exécution de code à distance.

// DANGEREUX : sérialisation de tous les champs@Serializabledata class User(    val name: String,    val passwordHash: String // fuite du hachage !)

// SÉCURISÉ : exclusion des champs sensibles@Serializabledata class SafeUser(    val name: String,    @Transient val passwordHash: String = "")

5. Utilisation non sécurisée de WebView (Android)

Lors du développement d'applications Android en Kotlin, WebView est souvent utilisé. Si JavaScript n'est pas désactivé ou si le filtrage n'est pas configuré, une attaque XSS est possible.

// DANGEREUX : JavaScript activé sans filtragewebView.settings.javaScriptEnabled = truewebView.loadUrl("file:///android_asset/index.html")

// SÉCURISÉ : désactiver JavaScript pour le contenu statiquewebView.settings.javaScriptEnabled = false// Ou utiliser une Content Security PolicywebView.loadDataWithBaseURL(null, content, "text/html", "UTF-8", null)

6. Gestion incorrecte des sessions

Stocker les jetons d'authentification dans SharedPreferences sans chiffrement est une erreur fréquente. Utilisez EncryptedSharedPreferences ou Android Keystore.

// DANGEREUX : stockage du jeton en clairval prefs = context.getSharedPreferences("auth", Context.MODE_PRIVATE)prefs.edit().putString("token", token).apply()

// SÉCURISÉ : stockage chiffréval encryptedPrefs = EncryptedSharedPreferences.create(    "secure_prefs",    MasterKey.DEFAULT_MASTER_KEY_ALIAS,    contex