IntelliJ "Unsafe Query" Inspection: Fix and Suppress It

What the “Unsafe query” inspection means

When IntelliJ IDEA highlights a line of SQL-building code with a warning that reads “String concatenation as argument to SQL query” or simply marks the query as an unsafe query, it is telling you that a non-constant value is being glued into a SQL statement and sent to the database. This is one of IntelliJ’s data-flow inspections, registered internally under the identifier SqlSourceToSinkFlow.

The IDE does not just pattern-match for a + next to the word SELECT. It runs a source-to-sink data-flow analysis: it traces a value backward from the point where it enters the query (the sink) to where it originated (the source). If that value is not a compile-time constant - for example, a method parameter, an HTTP request field, or a row read from another table - and it reaches the SQL string through concatenation, IntelliJ flags the path. Concatenating untrusted or non-constant data into SQL is the textbook cause of SQL injection, the vulnerability that sits near the top of the OWASP risk lists year after year.

The warning is a yellow highlight by default, not a compile error, so your code still runs. That is exactly why it is easy to ignore and why it is worth understanding properly.

Why IntelliJ flags it

The inspection is built on taint analysis. Think of every value in your program as either “clean” (a literal, a constant, a value you have explicitly sanitized) or “tainted” (anything IntelliJ cannot prove is safe). When a tainted value flows into a sink without being parameterized, the path lights up.

Consider this method:

public User findUser(Connection conn, String username) throws SQLException {
    String sql = "SELECT * FROM users WHERE username = '" + username + "'";
    Statement stmt = conn.createStatement();
    ResultSet rs = stmt.executeQuery(sql); // IntelliJ: unsafe query
    // ...
}

Here username is a method parameter. IntelliJ treats it as a source because nothing in the visible code proves it is safe. It is concatenated into sql, and sql is handed to executeQuery, a sink. If a caller passes ' OR '1'='1 - or worse, '; DROP TABLE users; -- - the database executes the attacker’s logic. The inspection is correct to fire.

The key signal is non-constant input reaching a query string by concatenation. Build the same string entirely from string literals and the warning disappears, because there is no tainted source to trace.

The right fix: parameterized queries

The correct fix is almost never “sanitize the string.” It is to stop building SQL by concatenation and let the database driver separate code from data. With a parameterized query, placeholders mark where values go, and the driver binds those values so they are always treated as data, never as executable SQL.

Bad - string concatenation:

String sql = "SELECT * FROM users WHERE username = '" + username + "'";
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(sql);

Good - JDBC PreparedStatement with placeholders:

String sql = "SELECT * FROM users WHERE username = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setString(1, username);
    try (ResultSet rs = ps.executeQuery()) {
        // read results
    }
}

The ? is a bind parameter. setString ensures the username is passed out-of-band, so ' OR '1'='1 becomes a literal search value rather than a piece of logic. IntelliJ recognizes this pattern as safe and removes the warning.

The same principle applies across the Java data-access landscape:

• JPA / Hibernate JPQL: use named parameters instead of concatenation.

  TypedQuery<User> q = em.createQuery(
      "SELECT u FROM User u WHERE u.username = :name", User.class);
  q.setParameter("name", username);

• Spring JdbcTemplate: pass arguments as varargs after the SQL.

  jdbcTemplate.query(
      "SELECT * FROM users WHERE username = ?",
      new UserRowMapper(), username);

• MyBatis: use #{}, which creates a bind parameter, not ${}, which performs raw string substitution and is itself a frequent source of injection.

  <select id="findUser" resultType="User">
    SELECT * FROM users WHERE username = #{username}
  </select>

One caveat that trips people up: bind parameters can only stand in for values, not for table names, column names, or keywords like ASC/DESC. When you genuinely need a dynamic identifier, validate it against a hard-coded allow-list before it touches the SQL. That allow-list check is also what turns a real warning into a legitimate suppression candidate, as covered next.

When it is a false positive and how to suppress it

The inspection is a heuristic, so it sometimes fires on code that is actually safe. Typical false positives:

• The value is assembled from compile-time constants that IntelliJ does not fold.
• A table or column name comes from an enum or a hard-coded Set allow-list.
• The input was already validated by a framework method IntelliJ cannot see through.

Once you have verified by hand that the input cannot be attacker-controlled, you can suppress the warning. IntelliJ offers several ways, in order of narrowest to broadest scope:

1. Suppress for a single statement. Put the caret on the warning, press Alt+Enter, expand the inspection submenu, and choose “Suppress for statement.” IntelliJ inserts a line comment:

//noinspection SqlSourceToSinkFlow
ResultSet rs = stmt.executeQuery(sql);

2. Suppress for the whole method with an annotation:

@SuppressWarnings("SqlSourceToSinkFlow")
public List<String> listColumns(String table) {
    // 'table' is checked against an allow-list above
}

3. Change severity or disable globally in Settings > Editor > Inspections, under the Java SQL group, where you will find “String concatenation as argument to SQL query” and the related SqlSourceToSinkFlow entries. You can untick it, drop it to a weak warning, or scope it to specific modules. Profile changes stored in .idea/inspectionProfiles are shared with your team through version control.

4. Mark inputs as safe. IntelliJ also lets you teach the analysis: annotating a SQL string with @Language("SQL"), or marking trusted parameters and methods through the “Configure inspection” dialog, helps the data-flow engine recognize a value as clean so it stops flagging downstream uses.

A hard rule: suppression is not a fix. It silences the IDE permanently for that scope, including on code that future edits might make genuinely unsafe. Only reach for it when the source is a constant, an allow-listed identifier, or input you have provably validated. When in doubt, parameterize instead.

Catching SQL injection beyond the IDE

The unsafe query inspection only protects code while it is open in your editor, and only for developers who have not disabled it. To enforce the same rule across every branch and every contributor, run a SAST scanner in CI that fails the build on injection patterns. Tools like Semgrep, SonarQube, and Snyk Code all carry SQL injection rules that perform their own taint tracking at build time, so a suppressed or ignored IDE warning still gets caught before it merges. For deeper, enterprise-grade scanning, dedicated platforms such as Checkmarx extend the same analysis across large polyglot codebases.

The pragmatic setup is layered: IntelliJ’s inspection gives instant feedback as you type, and a CI-level SAST gate provides the enforcement that an IDE warning cannot. See our best SAST tools for 2026 for a side-by-side comparison of where each tool fits.

Further reading

• Best SAST tools in 2026 - compare scanners that catch SQL injection in CI.
• Static code analysis tools guide - how taint analysis and data-flow inspections work under the hood.