To avoid any risk of SQL injection or destructive database operations, the system enforces a strict SQL-safety policy for all user-supplied queries:
1.Only SELECT statements are allowed
·No other SQL verbs are permitted. Anything like DELETE, UPDATE, INSERT, DROP, TRUNCATE, MERGE, EXEC, etc. is automatically rejected.
2.Queries are restricted to two specific tables
·Users can only run SELECT queries against our 275 attachment tables (header + detail).
·Any attempt to reference other tables is blocked.
3.Dangerous tokens are banned
The validator rejects queries containing:
·Multi-statement separators (;)
·SQL comments (--, /* ... */)
·System/procedural namespaces (sys., information_schema., sp_, xp_)
·Anything commonly used in SQL injection attacks
4.Subqueries are allowed
·Users can still write advanced SELECT statements, including nested queries, as long as they stay within the allowed tables and avoid banned keywords.
5.Purpose of this design
·Prevents the application from looking like it performed destructive actions
·Preserves user flexibility for complex filtering
·Eliminates the risk of the CLI becoming an attack vector
·Ensures the system is safe even if someone intentionally tries malicious input