Free Kotlin SAST scanner: find security bugs in Kotlin code

DepWarden's free Kotlin SAST scanner checks Kotlin source code against 18 security rules (including 10 Android-specific rules). Every rule maps to a CWE and the findings span 5 OWASP Top 10 categories, and every finding comes with an explanation, a fix and a before-and-after example. Paste a file, upload a zip or connect a repository: no account, and the results stay in a private, session-isolated workspace.

Kotlin is the default language for modern Android apps and is widely used with Spring Boot on the server. It shares Java's injection and cryptography pitfalls, plus Android-specific ones.

What DepWarden checks in Kotlin code

18 rules cover 16 distinct weakness types (2 critical, 12 high, 4 medium and 0 low severity).

Examples from the Kotlin rules

Android HostnameVerifier always returns true (CWE-297, critical)

A HostnameVerifier that always returns true accepts connections to servers whose certificate CN does not match the hostname, enabling MITM attacks.

Vulnerable:

val allowAll = HostnameVerifier { _, _ -> true }

Fixed:

// Remove the custom HostnameVerifier and rely on the OkHttp/JVM default

Remove the custom HostnameVerifier and rely on the system default.

Android dynamic DEX loading (CWE-494, high)

DexClassLoader or InMemoryDexClassLoader loads and executes code at runtime. If the source path is user-controlled or network-accessible, this enables code injection.

Vulnerable:

val loader = DexClassLoader(downloadedPath, cacheDir.path, null, parentLoader)

Fixed:

// Avoid runtime DEX loading; ship all code in the APK. If unavoidable,
// verify a signature over the DEX before instantiating the loader.

Avoid runtime class loading. If required, verify the integrity of the DEX file with a trusted signature before loading.

Android sensitive data stored on external storage (CWE-922, high)

Data written to external storage (SD card) is accessible to all apps and to USB-connected PCs. Never store sensitive data there.

Vulnerable:

val file = File(Environment.getExternalStorageDirectory(), "auth_token.txt")

Fixed:

val file = File(context.filesDir, "auth_token.txt") // private internal storage

Use getFilesDir() or getDataDir() for private app storage. Encrypt any file that must go to external storage.

Run it

• Paste code: open the SAST scanner, choose Kotlin and paste a file. You get findings in seconds.
• Upload a zip: files with these extensions are scanned: .kt, .kts. Dependency folders such as node_modules and vendor are skipped.
• Connect a repo: point DepWarden at a branch and it scans it once or on a schedule, with an emailed report.
• In CI: the GitHub Action runs SAST as its own step and can fail the build on severity. CI use goes through an API key and needs a plan that includes SAST.

- uses: Rushabh5000/depwarden-action@v1
  with:
    sast-dir: src
    sast-fail-on: high
  env:
    APP_API_KEY: ${{ secrets.APP_API_KEY }}

What it does not do

DepWarden's SAST engine uses pattern rules and taint-aware rules that require untrusted input to reach a dangerous call. It is not a full cross-file dataflow engine, so a bug that only appears when data crosses several files can be missed, and every static analyser reports some false positives. Treat findings as leads: review them, fix the real ones and suppress the rest with a written reason. SAST covers the code you write; for the packages you import, run software composition analysis too.

Frequently asked questions

Is there a free Kotlin SAST tool?

Yes. DepWarden's Kotlin scanner is free in the browser with no account: paste code, upload a zip or connect a repository. Running SAST from CI through an API key needs a plan that includes SAST.

Which Kotlin files are scanned?

.kt, .kts. Configuration and secret-bearing files such as .env and key files are also checked for hardcoded credentials, whatever language the project uses.

How do I fix what it finds?

Each finding names the weakness (CWE), explains why the code is risky, shows a vulnerable and a fixed version of the pattern, and gives the remediation. Fix the code, then scan again to confirm the finding is gone.

More

Other languages: Python, Java, JavaScript and TypeScript, PHP, Go (Golang), C#, Ruby, Swift, and secret scanning. Compare the options in free SAST tools compared, or start with what is SAST and SAST vs SCA.