Is there an existing issue for this?
Problem statement
filter (and row_filter) from rules are passed directly as sql expresssion without any safety check
Proposed Solution
For check.filter and row_filter — these are filter predicates, not full SQL queries. SELECT is never a valid keyword in a predicate expression, so it can be safely blocked. Add "select" to the forbidden_statements list in is_sql_query_safe and call it in DQRuleManager.filter_condition and at each row_filter call site.
For sql_expression — this is explicitly a "write SQL here" parameter where subqueries (EXISTS (SELECT ...)) may be legitimate. The right mitigation here is a clear docstring security warning rather than a keyword block.
Documentation — add a section to the user guide noting which parameters accept arbitrary SQL and that callers are responsible for ensuring values come from trusted sources when using them in automated or multi-tenant pipelines.
Additional Context
No response
Is there an existing issue for this?
Problem statement
filter(androw_filter) from rules are passed directly as sql expresssion without any safety checkProposed Solution
For check.filter and row_filter — these are filter predicates, not full SQL queries. SELECT is never a valid keyword in a predicate expression, so it can be safely blocked. Add "select" to the forbidden_statements list in
is_sql_query_safeand call it in DQRuleManager.filter_condition and at each row_filter call site.For sql_expression — this is explicitly a "write SQL here" parameter where subqueries (EXISTS (SELECT ...)) may be legitimate. The right mitigation here is a clear docstring security warning rather than a keyword block.
Documentation — add a section to the user guide noting which parameters accept arbitrary SQL and that callers are responsible for ensuring values come from trusted sources when using them in automated or multi-tenant pipelines.
Additional Context
No response