Security

VoidQL can be an authorization enforcement layer only for operations that actually pass through it. Its security boundary includes the application session, structure configuration, Drizzle schema, database driver, trigger functions, and every alternate database access path.

What the implementation provides

• Operation and role selection before query execution.
• Field validation against mapped table fields and permissions.
• Policy-derived row conditions combined with request filters.
• Drizzle-based operation construction rather than string concatenation in the main engine.
• Transactional execution of the main operation and triggers.
• Optional limits and returning-field restrictions.

What the application must provide

• Authenticated, server-derived user and role values.
• Complete policies for every protected operation and table.
• Protection against direct or raw database access that bypasses the handler.
• Database credentials with least privilege.
• Database constraints and transaction isolation suitable for the domain.
• Safe user-defined trigger functions.
• Error sanitization and security logging.

Trust boundaries

Value	Trust decision
user	Must be constructed from authenticated server state, not copied from client JSON
role	Must be resolved server-side
request fields and filters	Untrusted; validated against structure and permissions
structure/policies	Privileged code/configuration; review like application source
trigger functions	Privileged executable code
direct database clients	Potential bypass route

Secure configuration checklist

• Use explicit allowlists for sensitive tables.
• Add tenant or ownership conditions to every applicable operation.
• Test negative cases: wrong role, wrong tenant, forbidden field, invalid transition, missing filter.
• Do not return raw thrown errors to clients.
• Keep secrets and password hashes disallowed on every read/returning path.
• Audit background jobs, admin tools, migrations, and raw SQL separately.
• Pin and review dependencies before production use.

Known limitations

The project is experimental, has no published threat model or security audit in the supplied repository, uses several any types in security-sensitive shapes, and does not expose a stable typed error taxonomy. Database compatibility has not been demonstrated for every database type included in the union.

Reporting a vulnerability

The supplied SECURITY.md asks reporters to open an issue, but public issue disclosure is not appropriate for an unpatched vulnerability. Before launch, replace it with a private reporting address or GitHub private vulnerability reporting instructions.

← Understand the Engine · Troubleshooting →