SecurityField report

Vibe Coding Security: What DaloyJS Already Blocks Before Your AI Even Ships

Aikido's 'WTF is Vibe Coding Security' post lists the usual suspects: SQL injection, path traversal, hardcoded secrets, unlocked admin routes, missing input sanitization, dependency rot. This post shows which of those a DaloyJS app already blocks by default, even when the code is written by a sales rep at 1am with an AI assistant, and the small list of things you still have to opt into.

Devlin Duldulaosoftware engineer & published book authorJune 10, 202610 min read

A reader sent Aikido's "WTF is Vibe Coding Security" and asked which risks DaloyJS already blocks.

For the unfamiliar: vibe coding is when someone, often someone who is not a developer, describes what they want in English and ships whatever the model writes. Agentic coding is the same thing with the model also installing the dependencies, running the tests, and pushing the PR. The Aikido post lists the usual scary outcomes: SQL injection, path traversal, hardcoded secrets, an admin route left mounted on the public app (the "Tea app" story), and an AI agent that deleted a production database while "lying about unit tests" (the Replit / SaaStr story).

I read it, opened DaloyJS, and went through each risk to see what we already block, what needs one opt-in line, and where DaloyJS can't help. Below is that mapping. The TL;DR: if a sales rep uses an AI assistant to scaffold a DaloyJS app at 1am, the boring stuff, body limits, prototype pollution, header splitting, path traversal, secret-shaped logs, is on before they type their first prompt. What they still have to choose is which routes need auth and where the admin surface lives. Those are policy, not defaults.

Risk 1: SQL injection

Aikido: 'SQL injections, path traversal, hardcoded secrets.'

DaloyJS blocks: Standard Schema (Zod / Valibot) validation lives in the route definition, not in an afterthought. A declared schema is enforced before the handler runs; a route without one still gets the raw ctx.request, so look for that in review. /docs/security/sql-injection documents the per-ORM patterns; the scaffolder ships Prisma / Drizzle / TypeORM templates that are parameterized by construction.
You still own: Pick a real ORM. Don't write template-string SQL. The framework will not stop you from doing the wrong thing inside your handler, but it will hand you a fully-typed, validated input object so you have no excuse.

DaloyJS doesn't ship an ORM. That's deliberate, pinning one ORM would be the same kind of opinionation that gets frameworks in trouble. What it does ship is a route shape where the input is validated before your handler runs:

// What a "vibe-coded" route looks like in DaloyJS.
// The schema lives in the route, and a declared schema runs before the handler.
import { z } from "zod";
import { App } from "@daloyjs/core";

export const app = new App();

app.route({
  method: "POST",
  path: "/orders",
  operationId: "createOrder",
  request: {
    // Declared here, enforced before the handler runs. Unknown content
    // types get 415. (A route with no body schema still gets the raw
    // ctx.request, so this line is the one to look for in review.)
    body: z.object({
      sku: z.string().min(1).max(64),
      quantity: z.number().int().positive().max(1000),
      customerEmail: z.email(),
    }),
  },
  responses: {
    201: { description: "created" },
  },
  handler: async ({ body }) => {
    // 'body' is fully typed AND already validated. The raw ctx.request is
    // still there, but nothing here needs it.
    return { status: 201, body: { id: crypto.randomUUID(), ...body } };
  },
});

And a documented path for the database layer:

// DaloyJS does not ship an ORM, on purpose.
// What it DOES ship is a docs page that says: bring a real ORM, never
// concatenate user input into SQL, and the validated 'body' / 'query'
// objects are the inputs your ORM should see.
//
// See /docs/security/sql-injection and /docs/orm for the per-ORM guidance.
import { prisma } from "./db.js";

app.route({
  method: "GET",
  path: "/products",
  operationId: "listProducts",
  request: {
    query: z.object({
      q: z.string().max(120).optional(),
      limit: z.coerce.number().int().min(1).max(100).default(20),
    }),
  },
  responses: { 200: { description: "ok" } },
  handler: async ({ query }) => {
    // Parameterized. No template-string SQL anywhere in the call site.
    const products = await prisma.product.findMany({
      where: query.q ? { name: { contains: query.q } } : undefined,
      take: query.limit,
    });
    return { status: 200, body: products };
  },
});

Full guidance: /docs/security/sql-injection and the per-ORM pages under /docs/orm.

Risk 2: Path traversal

Aikido: '..serving up /etc/passwd to anyone who tries.'

DaloyJS blocks: The router rejects '..' segments, '//', encoded NULs, and percent-encoded traversal sequences before the route is matched. Returns 404 with no handler invocation.
You still own: Constrain :param shapes with a Zod regex anyway. Defense in depth costs you one line.

// The router rejects path traversal before any handler runs.
//
//   GET /files/..%2F..%2Fetc%2Fpasswd      -> 404
//   GET /files/%00secret.txt               -> 404
//   GET /files//etc/passwd                 -> 404
//   GET /files/%2e%2e/secret                -> 404
//
// You don't have to remember this in every route. The router does.
// (See /docs/security/runtime-protections for the full list.)
app.route({
  method: "GET",
  path: "/files/:name",
  operationId: "getFile",
  request: {
    params: z.object({
      // Belt-and-braces: still constrain the param shape at the route level.
      name: z.string().regex(/^[a-z0-9._-]{1,128}$/i),
    }),
  },
  responses: { 200: { description: "ok" } },
  handler: async ({ params }) => ({
    status: 200,
    body: await readFile(params.name),
  }),
});

The full list of what the router refuses to walk into is in /docs/security/runtime-protections.

Risk 3: Hardcoded secrets and AI-generated supply-chain rot

Aikido: 'hardcoded secrets' + the broader agentic-coding worry that an AI agent installs whatever npm package its prompt mentioned.

DaloyJS blocks: Repo-wide CI gates that block leaked credentials, base64-smuggled payloads, invisible-unicode Trojan Source, install-time lifecycle scripts in the published packages' own manifests (the #1 npm attack vector), remote exec (curl|sh, eval(fetch())), unpinned GitHub Actions, and unauthorized license categories. CycloneDX and SPDX SBOMs are generated and verified on every release, and the package is published with npm provenance. @daloyjs/core itself ships with zero runtime dependencies, there is no transitive blast radius.
You still own: These gates run in the DaloyJS repo. Scaffold with --with-ci to get lockfile verification, secret scanning, CodeQL, OSV and Scorecard workflows in your own project. Don't turn ignore-scripts off because a dependency 'needs' a postinstall, that's the attack.

bash

# The DaloyJS repo runs these CI gates on every PR. They are not
# aspirational - a failure blocks merge. (Scaffolded projects do not get
# them; `create-daloy --with-ci` adds lockfile verification, secret
# scanning, CodeQL, OSV and Scorecard workflows instead.)
pnpm verify:no-leaked-credentials      # AWS keys, GCP keys, GH tokens, npm tokens
pnpm verify:secret-comparisons         # all secret compares use timingSafeEqual
pnpm verify:no-encoded-payloads        # base64 blobs (a common AI-slop smuggling vector)
pnpm verify:no-invisible-unicode       # Trojan Source / zero-width / bidi
pnpm verify:no-remote-exec             # no curl|sh, no eval(fetch(...))
pnpm verify:no-lifecycle-scripts       # no install / postinstall / prepare scripts
pnpm verify:no-registry-exfiltration   # no sneaky POSTs to a registry-shaped URL
pnpm verify:no-runtime-deps            # @daloyjs/core ships ZERO runtime deps
pnpm verify:actions-pinned             # every GH Action pinned to a commit SHA
pnpm verify:dep-licenses               # license allow-list
pnpm verify:sbom                       # CycloneDX + SPDX SBOMs match the manifests

The full reasoning behind each gate is in "Supply-chain hardening for TypeScript libraries". The shorter version: attackers do not need a 0-day if they can ship a malicious postinstall, and AI agents do not inspect scripts blocks before running npm install. Turning lifecycle scripts off (ignore-scripts) is what stops the next Shai-Hulud-style install-script worm. It does not stop a chalk-style compromise, where the payload runs when your code imports the package; the 24-hour release-age cooldown and a committed lockfile are what help there.

Risk 4, Unlocked admin routes (the "Tea app" story)

Aikido: 'admin routes left unlocked, exposing user data to anyone who stumbled across the endpoint.'

DaloyJS blocks: ipRestriction() and basicAuth() are first-class middleware. /docs/security/admin-panels exists specifically to argue that the safest admin route is the one that isn't mounted on the public app at all, and shows the multi-App pattern that makes that easy.
You still own: Pick a pattern: separate App on a separate hostname (best), or /admin mounted with ipRestriction + basicAuth (acceptable). The framework refuses to invent a default 'admin' user, there is none, so a forgotten password is not a backdoor.

// The "Tea app" lesson, never leave an admin route mounted on the
// public app without auth + network restriction. Daloy gives you both
// as boring middleware so the wrong default is hard to type.
import { App, every, ipRestriction, basicAuth, timingSafeEqual } from "@daloyjs/core";

export const adminApp = new App();

// app.use() takes one hooks bundle; every() runs both in order.
adminApp.use(every(
  ipRestriction({ allow: ["10.0.0.0/8"] }),
  basicAuth({
    realm: "admin",
    verify: (user, pass) =>
      timingSafeEqual(user, process.env.ADMIN_USER!) &&
      timingSafeEqual(pass, process.env.ADMIN_PASS!)
        ? { sub: "admin" }
        : false,
  }),
));

// Keep the admin app off the public deploy entirely when you can -
// /docs/security/admin-panels has the full pattern (separate process,
// separate hostname, separate ingress).

The dedicated page is /docs/security/admin-panels. If the "Tea app" team had read it, they'd have shipped an internal-only deploy and the breach would not have happened. Frameworks cannot force deployment policy, but DaloyJS makes the internal-only configuration the easier path.

Risk 5: Missing input sanitization

Aikido: 'input sanitization' is one of the four basics the vibe-coder checklist asks for.

DaloyJS blocks: Standard Schema everywhere (Zod, Valibot, ArkType all supported). Body, query, params, and headers are all validated against a declared schema. Unknown fields are stripped or rejected depending on your schema, the wrong type gets a 422 before the handler runs, and the validated value is what the handler's typed arguments carry.
You still own: Write the schema. The framework will hold the line.

This is the same pattern as Risk 1, applied to every input surface, not just bodies. The route contract is the validation layer, there is no "remember to call zod.parse" convention. If the body schema rejects, the handler never runs. The honest limit: a route that declares no body schema still gets the raw ctx.request, and nothing stops a handler from reading it, so "does this route declare its inputs?" is still a review question.

Risk 6, Agentic coding doing things the prompt didn't ask for

Aikido / Replit story: 'the AI started lying about unit tests, ignored code freezes, and eventually deleted the entire SaaStr production database.'

DaloyJS blocks: fetchGuard(), a guarded fetch that refuses cloud metadata, loopback, and RFC1918 targets by default. requestTimeoutMs + bodyLimitBytes, bounded resource use. Per-request structured logs with correlated request IDs go to your SIEM, so 'the AI agent did what?!' becomes a query, not an archeology dig. The scaffolder ships an AGENTS.md and a daloyjs-best-practices SKILL.md so the agent reads the rules before it writes code.
You still own: Don't give the production-DB password to the agent. Run agentic tools against a sandbox account. Treat AI commits like junior-dev commits, review them. The framework cannot stop you from handing your prod credentials to a model.

// "AI agents that can install dependencies, run tests, refactor files,
// and update infrastructure" - Aikido's exact words - also tend to write
// handlers that call any URL the prompt suggests. fetchGuard() returns a
// guarded fetch (it is not middleware and does not patch globalThis.fetch)
// that refuses cloud metadata IPs (169.254.169.254), localhost, and
// RFC1918 ranges, and re-checks every redirect hop.
import { fetchGuard } from "@daloyjs/core";

export const safeFetch = fetchGuard();
// Default-blocked ranges (for clarity):
// 169.254.0.0/16, 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12,
// 192.168.0.0/16, ::1, fc00::/7. Cloud metadata stays blocked
// even if you pass allowPrivate / allowLinkLocal.

// In a handler: use safeFetch for every URL that came from a user or a model.
// await safeFetch(url); // throws SsrfBlockedError on a blocked target

The "agent reads the rules before it writes code" piece is covered in "Designing for Coding Agents". The point of scaffolding AGENTS.md is exactly the "PromptBOM" idea the Aikido post pitches at the end, give the agent provenance and rules before it generates, not after.

The assume-the-vibe-coder-skipped-it defaults

The article's most useful line: "Treat AI code like a junior developer wrote it." Translated into framework defaults, that means the dangerous things have to be off when nobody remembered to turn them off. That's the constructor:

// The "assume the vibe-coder will skip security" defaults DaloyJS
// turns on without asking - none of these need a flag.
//
// 1. Body-size DoS: streamed read, 1 MiB default cap, Content-Length
//    checked first -> 413. AI agents love to forget body limits.
// 2. Request timeout: 30s default. Slow-loris and hung handlers die.
// 3. Prototype pollution: __proto__ / constructor / prototype stripped
//    from every JSON body the framework parses. A vibe-coded user-update route can't be
//    abused into mass assignment of internal flags.
// 4. CRLF / header splitting: rejected at write time. Set-Cookie smuggling
//    via a 'name' field never reaches the wire.
// 5. Path traversal: '..' and '//' rejected before routing.
// 6. Production redacts 5xx bodies: no stack traces, no internal hostnames,
//    no DB error messages leaked to attackers.
// 7. Method confusion: real 405 with Allow header - not a misleading 404
//    that helps enumeration tools.
// 8. Unsupported content types on body routes: 415. No silent JSON-parse
//    of a text/plain payload.
// 9. session() and csrf() cookies (once you add them) default to the
//    __Host- prefix, Secure, SameSite=Lax (session: HttpOnly too).
//
// All of the above are the constructor:
new App();

What DaloyJS does not cover

Destructive database privileges can still ruin production from inside a handler. Give agents read replicas and least-privilege database roles.
AI-generated business logic still needs review. Typed routes, typed clients, and OpenAPI give reviewers and SAST tools a structured surface to inspect.
Authentication remains an explicit per-route decision because some routes are public. Daloy provides jwk(), basicAuth(), bearerAuth(), session(), and the auth-slice pattern.
AI moderation and runtime intrusion detection need separate systems. Daloy provides the event stream a detector consumes.

A vibe-coder prompt I would actually use

// A 60-second checklist a vibe-coder can paste into their prompt.
//
//   "Use DaloyJS. Every route MUST have a Zod schema for body, query,
//    and params. Use prisma (or drizzle) - never template-string SQL.
//    Mount admin under /admin with ipRestriction + basicAuth, or move it
//    to a separate adminApp on a different deploy. Add secureHeaders(),
//    rateLimit(), and fetchGuard() in app.ts. Never read process.env at
//    module top-level for secrets; read inside the handler so the boot
//    guards catch missing values. Scaffold with --with-ci."
//
// That is the entire delta between "vibe-coded app that ships" and
// "vibe-coded app that doesn't end up on a breach blog."

That paragraph plus pnpm create daloy@latest is the entire setup. The scaffolded project ships with a hardened CI bundle (--with-ci, on by default: lockfile-source check, CodeQL, OSV, secret scanning, Scorecard), the AGENTS.md the model needs, the security docs linked from the README, and the secure-by-default constructor. The sales rep at 1am has to actively work to disable any of it.

What DaloyJS covers

DaloyJS defaults cover the common mistakes in the Aikido list even when a generated handler omits them. Application owners still have to choose an identity provider, restrict the database role, protect production credentials, and review changes.