public class GormQuerySafetyTransformer
extends org.codehaus.groovy.ast.ClassCodeVisitorSupport

org.codehaus.groovy.ast.ClassCodeVisitorSupport that detects GORM HQL/Cypher query text built from a org.codehaus.groovy.ast.expr.GStringExpression that Groovy coerced to a plain String before it reaches a GORM query method, e.g.:

String query = "from Book where name = ${userInput"   // coerced to String right here
 Book.executeQuery(query)                                // -> raw, unescaped text, no binding
 }

When a groovy.lang.GString is passed directly to a GORM query method, GORM binds each interpolated value as a query parameter — safe. Once the GString has been coerced to a String (an explicit String-typed local, a .toString() call, or an as String/cast coercion), that information is gone: a String carries no trace of ever having been a GString, so this can only be caught here, before the coercion erases it — a runtime check at the query boundary is structurally blind to this case.

A GString does not have to be flattened directly at the call site to be unsafe — aliasing it through one or more intermediate variables still loses the binding the moment it is assigned to a String-typed variable, however many hops away that happens:

def g = "from Book where name = ${userInput"   // g: still a live GString
 String q = g                                     // flattened HERE, not at the executeQuery call
 Book.executeQuery(q)
 }

This is a build-breaking error for the local-variable case above, because the detection is precise: every flattening point is visible in the method being compiled. Two related patterns are lower-confidence and instead reported as compile-time warnings, which do not fail the build:

• Fields. A String-typed field initialized from an interpolated GString, or assigned one via this.field = ..., that later reaches a query method through this.field. Unlike locals, a field can be reassigned from a constructor, another method, or a subclass that this check never visits, so it is flagged rather than failed.
• String concatenation. Query text built with + from a non-constant value and no GString involved at all, e.g. "select ... " + userInput. This is a real injection shape, but concatenation is common enough for benign, non-query purposes that a hard failure would be too blunt an instrument. Concatenating a GString with anything else (e.g. "...${x..." + " order by title"}) is a different matter - GString.plus returns a plain String, so this flattens the interpolation immediately and is reported as the build-breaking error above, not this warning.

Both warnings share the same SUPPRESS_WARNINGS_VALUE suppression as the error case.

Known limitations (deliberate scope):

• Intraprocedural only — a flattened String built inside a helper method and returned to the caller is invisible to this check.
• Reassignment tracking for locals is branch-sensitive across a single if/else (a variable unsafe after either branch stays unsafe after the statement), but not across loops, switch, or try/catch - and is last-write-wins for fields, which are not branch-sensitive at all.
• Field tracking only recognizes a directly-interpolated GString initializer or this.field = ... assignment - it does not follow aliasing chains or .toString()/cast coercions the way local tracking does.
• Does not detect raw JDBC via groovy.sql.Sql, or any datastore whose query methods use names outside CANDIDATE_METHODS.

Since:

8.0