Code ScanningSAST by Language

Kotlin SAST

What xgrep detects in Kotlin — injection, XSS, unsafe deserialization, weak crypto, insecure TLS, open redirect, and ReDoS — for Android apps and JVM backends.

Kotlin SAST

xgrep parses .kt / .kts into tree-sitter ASTs and ships 14 rules, 8 of them taint-based, covering both Android apps and JVM server code (Ktor, Spring).

xgrep scan --include '*.kt' .

What xgrep detects

Injectionsql-injection (SQLite rawQuery/execSQL and JDBC), command-injection (Runtime.exec / ProcessBuilder), code-injection (ScriptEngine.eval, Groovy).

Cross-site scriptingreflected-xss: request input written to a servlet response, a Ktor respondText(..., ContentType.Text.Html), or an Android WebView.loadData.

Open redirectopen-redirect: untrusted input flowing into sendRedirect / Ktor respondRedirect, with relative-path and allowlist guards recognised.

SSRFssrf: tainted URLs reaching URL.openConnection/OkHttp.

Deserializationunsafe-deserialization: ObjectInputStream.readObject, SnakeYAML load, and XStream fromXML.

Path traversalpath-traversal.

Cryptoweak-cipher (DES/ECB/Blowfish), weak-hash (MD5/SHA-1), insecure-random (a non-CSPRNG used for a token/key/nonce/salt).

TLStrust-all-certificates: an X509TrustManager with an empty checkServerTrusted, or a HostnameVerifier that always returns true.

Regex / DoSregex-injection: untrusted input compiled as a regular expression (ReDoS), suppressed when Regex.escape / Pattern.quote is applied.

Androidwebview-js-interface: addJavascriptInterface exposed to untrusted content.

Taint analysis

8 rules use taint mode: untrusted input — a servlet parameter/header, a Ktor request header, or an Android Intent extra — must reach a dangerous sink before the rule fires, and recognised sanitizers (HTML-encoders, Pattern.quote/Regex.escape, type conversions) stop the flow.

Scanning compiled Kotlin

You do not need the sources. Point xgrep at the jar and it reads the .class files inside:

xgrep scan build/libs/checkout-api.jar

Findings come back under the Kotlin rules, not the Java ones — a .class file compiled from Kotlin is recognised as Kotlin, so you get kotlin-command-injection from the artifact exactly as you do from the .kt sources, at the same source line when the build kept debug information. A mixed Java/Kotlin jar reports each class under its own language.

Compiled analysis covers command-injection, sql-injection, path-traversal, reflected-xss and code-injection; the other Kotlin rules apply to source only. Ktor request accessors are recognised in source but not yet in compiled classes — servlet, Android Intent/Uri and System.getenv sources are.

See Scanning a build artifact for what else an artifact scan reports.

See also Secrets scanning and the CLI reference.

On this page