detecting-sql-injection

Run the scan_sqli.py script against your source directory; it applies Semgrep rules for JdbcTemplate string concatenation, JPA createQuery concatenation, and MyBatis ${} interpolation. Each candidate is then verified in context to confirm whether user input actually reaches the query.

#{} uses PreparedStatement parameter binding and is safe against SQL Injection. ${} performs raw string substitution into the SQL, so it is dangerous when the value comes from user input; it is only acceptable for identifiers like ORDER BY columns after allowlist validation.

Yes, the scanner falls back to regex-based grep detection when Semgrep is unavailable. The fallback has lower precision and recall, so it prints a warning and the AI verification step becomes more important to filter false positives.

Yes, the jsp-legacy ruleset covers JSP scriptlet Statement string concatenation, prepareStatement inline concatenation, and MyBatis or iBATIS mapper XML under sqlmap directories. Stack detection uses signals like web.xml, .jsp files, and pom.xml.

The scanner intentionally casts a wide net, flagging patterns like ${} that may use safe internal configuration values rather than user input. The second-stage AI verification traces input sources and allowlist checks, and excluded items are documented in the report's false-positive section.

Skip it for vulnerability classes other than SQLi such as XSS or CSRF, which have their own skills, and for batch queries or hardcoded SQL with no user input. It performs static analysis only, so confirming live exploitability requires the separate penetration testing skill.