Kotlin Application Security: Top 10 Vulnerabilities for Beginners

Kotlin Application Security: Top 10 Vulnerabilities for Beginners

Kotlin is a modern programming language actively used for developing Android applications, server-side solutions (Ktor, Spring Boot), and even frontend (Kotlin/JS). However, like any other language, Kotlin is susceptible to vulnerabilities, especially if the developer is just starting out. In this article, we will break down the top 10 vulnerabilities of Kotlin applications that every beginner developer should know. We will look at code examples and provide practical tips for fixing them.

1. Ignoring Null Safety

Kotlin is famous for its safe handling of null values (Null Safety). However, beginners often use the !! operator (not-null assertion), which leads to NullPointerException.

// Bad: risk of NPE\nval name: String? = null\nprintln(name!!.length)\n\n// Good: safe call\nprintln(name?.length ?: "Name is missing")

Recommendation: Avoid !!. Use the Elvis operator (?:) or let/also.

2. Unsafe Storage of Secrets (Hardcoded Secrets)

Storing API keys, tokens, and passwords directly in the code is a serious mistake. An attacker can easily extract them from the APK file.

// Bad: token in code\nval apiToken = "sk-1234567890abcdef"\n\n// Good: using BuildConfig or NDK\n// In build.gradle: buildConfigField "String", "API_TOKEN", "\\"${apiToken}\\""

Recommendation: Use environment variables, BuildConfig, or secure storage (Android Keystore).

3. SQL Injections in Android (Room/Exposed)

Even with ORM (Object-Relational Mapping), you can allow injection if you use raw SQL queries with string concatenation.

// Bad: vulnerable to injection\nval query = "SELECT * FROM users WHERE name = '$userInput'"\n\n// Good: parameterized query\nval query = "SELECT * FROM users WHERE name = ?"\nval cursor = db.rawQuery(query, arrayOf(userInput))

Recommendation: Always use parameterized queries or safe APIs (Room @Query with parameters).

4. Unsafe Logging

Logging sensitive data (passwords, card numbers) in production can lead to information leakage.

// Bad: logging password\nLog.d("Auth", "User password: $password")\n\n// Good: logging only the fact\nLog.d("Auth", "User authentication attempt")

Recommendation: Use logging levels and filters. In production, disable Log.v and Log.d.

5. Improper Use of SharedPreferences

SharedPreferences by default store data in an XML file without encryption. If the device is rooted, the data is accessible to an attacker.

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

Recommendation: For confidential data, use EncryptedSharedPreferences or DataStore with encryption.

6. Deserialization Vulnerabilities (JSON/Gson/Moshi)

When deserializing untrusted data, arbitrary code execution or memory leaks can occur.

// Bad: using Gson without validation\nval user = Gson().fromJson(jsonString, User::class.java)\n\n// Good: vali