Common Security Risks and Defenses
TeaQL provides structural defenses against common web application vulnerabilities by moving business data access through generated APIs, runtime context, and explicit audit metadata. These mechanisms reduce common risk, but they still need to be paired with application-specific authorization rules, dependency management, and normal security review.
Preventing SQL Injection (SQLi)
TeaQL's generated Q APIs reduce SQL injection risk by keeping ordinary business queries away from handwritten string concatenation. Query values are represented as structured API calls and bound by the runtime/provider layer.
Provider-level code and any explicitly handwritten SQL still require normal parameter binding and review.
Preventing Broken Object Level Authorization (BOLA/IDOR)
TeaQL uses UserContext at the query execution boundary so tenant scope, actor identity, and authorization policy can be applied consistently. This gives teams one runtime boundary to review instead of spreading object-level checks across many handwritten queries.
The model and runtime policy must still define the correct tenant and ownership rules for the application.
Preventing Mass Assignment
TeaQL mutation APIs make saved and updated fields explicit. This reduces the chance that an inbound payload silently overwrites fields that were not meant to be user-controlled.
Sensitive workflows should still review which fields are selectable, writable, masked, or audit-only.
Preventing Excessive Query Complexity
Generated APIs and runtime limits can bound expensive traversal and loading patterns. This helps reduce the risk of unbounded nested queries consuming database, CPU, or memory resources.
Application teams should still choose limits, pagination defaults, and relationship loading patterns that match their workload.
Deployment and Supply Chain Notes
Rust single-binary deployments and minimal container images can reduce runtime footprint and exposed operating-system packages. Rust's memory safety also removes broad classes of memory errors from safe Rust code.
These benefits do not replace dependency review, image scanning, Java framework patching, or review of any unsafe or provider-level code.