Skip to content
Genie

Parameter sanitisation

Per-view SQL (the Sql, form SQL, submit SQL and DeleteSql blocks) can reference parameters by name. A client sends a parameter dictionary with each request. Left unchecked, a caller could send a parameter the view’s SQL happens to bind but the UI never exposes — e.g. IsAdmin, OwnerId, CompanyId — and mass-assign it. ParameterSanitizer makes the implicit allowlist explicit.

The rule

Section titled “The rule”

ParameterSanitizer.Sanitize(...) returns a new dictionary containing only the entries whose key (with any leading @ stripped) is:

  • in the server-declared allowlist for the active view — its declared EditorFields / FormParameters and primary key; or
  • prefixed with a nested-view convention prefix: Parent__, Form__, Table__ (these thread parent-context filters from an outer view into a nested sub-view); or
  • a framework-reserved correlation key: PageViewId, ViewId.

Everything else is dropped. In particular:

Why it matters

Section titled “Why it matters”

SQL Server silently ignores dictionary keys the SQL doesn’t bind, so an undeclared key is usually harmless — until a view’s SQL references a sensitive column the UI doesn’t render. The sanitiser closes that gap uniformly instead of relying on every view author to remember it. Comparison is case-insensitive and @-insensitive.

Don’t bypass it

Section titled “Don’t bypass it”

Every data path runs caller parameters through the sanitiser before they reach SQL. When you add a new endpoint or service that accepts client parameters, route them through ParameterSanitizer with the view’s declared allowlist — don’t hand raw caller input to a SQL block.

Section titled “Related”