--- title: Why Kovo? description: How Kovo makes the safe thing the default — owner-scoped reads, escaped output, parameterized queries are what you write, and the unsafe version fails the build or the database refuses it. order: 1 --- # Why Kovo? Most of a web app's security is a discipline you have to remember. Scope every query to the current user. Escape every string before it reaches the page. Parameterize every SQL statement. Miss one — one forgotten `WHERE user_id = ?` — and it isn't a bug that renders blank. It's a stranger reading someone else's orders. Kovo's bet is that human memory is the wrong place to keep a security boundary. So the safe shape is the one you write by default, the unsafe shape is a build error, and where the compiler can't prove it, the database itself refuses. Here's the whole idea in one line. You mark who owns a row: ```ts import { kovo } from '@kovojs/drizzle'; import { pgTable, text } from 'drizzle-orm/pg-core'; const orders = pgTable( 'orders', { id: text('id').primaryKey(), userId: text('user_id').notNull(), }, kovo((columns) => ({ domain: 'order', owner: columns.userId })), ); ``` Now every read of `orders` is scoped to the signed-in user — enforced by Postgres, at the connection, not by a `WHERE` clause you remembered to add. Delete the filter, write the query wrong, reach the table through a different handle: the database still returns only that user's rows. Forget to scope an owned table at all, and the build fails at the query before it ships. This page shows that pattern applied to the three mistakes that leak data: reading another user's rows (IDOR), SQL injection, and XSS. Real code, both sides — what you write, and what Kovo won't let you write. ## Safe by construction, then defense in depth Three things have to hold for "you can't hold it wrong" to mean anything: 1. **The safe shape is the default.** Ordinary code — a plain query, `{user.name}` in your markup — is already scoped, already escaped. There's no separate "secure" variant to reach for. 2. **The unsafe shape doesn't compile.** Where static analysis can prove a trust-boundary mistake — an unescaped sink, a raw SQL string, an owned table read with no scope — it's a build error, not a lint you can wave through. 3. **Where it can't prove it, it fails closed.** Authorization is a runtime fact — does _this_ user own _this_ row? — so it's enforced at runtime, by the database, default-deny. The engine says no without needing a proof. And every deliberate exception is visible. When you genuinely need raw HTML or raw SQL, you pass a branded value — `trustedHtml(...)`, a branded `sql` — and it shows up in `kovo explain`. There is no silent way to opt out of a guarantee. The opt-outs are enumerable. ## IDOR: reading another user's rows Orders are owned by `userId`, so this loader is already scoped to the caller. There is no `userId` in the query, and it doesn't need one: ```ts // Source: examples/commerce/src/queries.ts orders = pgTable( 'orders', { /* … */ }, kovo((columns) => ({ owner: columns.userId })), ); const orderHistory = query({ guard: guards.authed(), load: (_input, context) => context.db.select().from(orders), // returns only the caller's orders }); ``` The Postgres role this query runs as can only see rows where `userId` matches the session. Kovo sets the principal per request; the database does the filtering. (Our own commerce example keeps an explicit `.where(eq(orders.userId, userId))` — for readers, not for safety. Deleting it changes nothing about who can see what.) Now the version that leaks in most stacks — an owned table read with no way to scope it: ```ts db.select().from(orders); // ✗ build error — read of an owned table is not owner-scoped ``` At build, that's a scoping diagnostic. At runtime, if you route around the check somehow, the database returns zero rows — not everyone's. Reading across users on purpose (an admin report) is a named capability, `crossOwnerRead`, which requires an admin role and is logged. The wide read exists. It just can't happen by accident. ## Injection: SQL from a string The query builder binds values. User input is a parameter, never concatenated into text: ```ts db.select().from(products).where(eq(products.id, input.id)); // input.id is bound ``` When you need raw SQL, it only reaches the database as a branded `sql` value, which parameterizes every interpolation for you: ```ts db.select() .from(products) .where(sql`id = ${input.id}`); // ${input.id} is a bound parameter, not text ``` A hand-built string doesn't carry that brand, so it can't reach a managed handle. Truly unsafe SQL — building the statement text yourself — means calling `trustedSql(...)` on purpose, the audited escape that appears in `kovo explain`. ## XSS: a string that's really markup Output is escaped. A name with a `