Aikido's Top 10 App Security Problems, Mapped to DaloyJS (and the One Gap We Just Closed)

A reader pinged me with Aikido's "Top 10 App Security Problems" post and the same question I get every time one of these lists makes the rounds: are we doing anything about this?It's a fair question. The post is a no-nonsense run-down — SQL/NoSQL injection, XSS, SSRF, path traversal, XXE, deserialization, shell injection, LFI, prototype pollution, open redirects. The basics. The stuff that's been on every top-10 list since 2007 and still ships in production CVEs every week.

I went down the list with our framework open in another window. The honest result: nine out of ten are already covered — most of them by default, a couple with a single opt-in line. One — open redirects— was a real gap. So I shipped a helper for it. You'll see it below as safeRedirect() in 0.35.0.

Below is the per-item map. No marketing voice, no "trust us, we're secure." Just what the constructor gives you, what you opt into, and what stays your problem.

#1 — SQL & NoSQL injection

The injection itself happens at your database driver, not at the HTTP layer — so this is half-shared. What DaloyJS does is make the two classic Mongo-flavored payloads impossible to pass through the request boundary unnoticed:

// Mongo / NoSQL operator injection — \$ne, \$gt, \$where as object
// values — is a one-liner refusal in DaloyJS.
import { assertNoMongoOperators } from "@daloyjs/core";

app.post("/users/login", async (ctx) => {
  const body = await ctx.req.json();
  assertNoMongoOperators(body); // throws on { password: { $ne: null } } etc.
  // proceed with your authenticator
});

For SQL, the framework's contribution is that validated input comes out as the type you declared. A schema that expects email: z.string().email() will not let email = " OR 1=1 --"reach your handler looking like a string. You still have to call the driver correctly — but you don't get to claim you concatenated a string "because the type system told you to."

#2 — Cross-site scripting (XSS)

The default response shape is JSON. JSON does not execute. The risk window is your dynamic HTML routes, your SSR layer, and your front-end framework — and Daloy's job there is to make sure the browser's defenses (CSP, Trusted Types, nosniff) are on by the time you start rendering. They are.

#3 — Server-side request forgery (SSRF)

// SSRF defense at the runtime fetch boundary.
import { App, fetchGuard } from "@daloyjs/core";

export const app = new App();

app.use(fetchGuard({
  allow: ["https://api.example.com", "https://*.s3.amazonaws.com"],
  // Default-blocks 169.254.169.254 (cloud metadata),
  // 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,
  // ::1, fc00::/7. Redirects re-validate at every hop.
}));

This is the one I'm proudest of, because the most-quoted SSRF CVEs of the last five years — Capital One, Shopify, plenty of others — would have failed against a re-validating fetch wrapper. Daloy's does re-validate every hop. A 302 to 169.254.169.254 is just as dead as a direct one.

#4 — Path traversal

// Path traversal payloads are rejected at the routing layer,
// before any handler runs.
//
//   GET /files/..%2F..%2Fetc%2Fpasswd   -> 400 BadRequest
//   GET /files/..%252F                  -> 400 BadRequest (double-encoded)
//   GET /files/%00../secret             -> 400 BadRequest (encoded NUL)
//
// When a handler needs to accept a *user-supplied* file path —
// download links, attachment storage — use the helpers in @daloyjs/core:
import { assertSafeRelativePath, sanitizeFilename } from "@daloyjs/core";

app.post("/upload", async (ctx) => {
  const body = await ctx.req.formData();
  const file = body.get("file") as File;
  const name = sanitizeFilename(file.name);   // strips .., /, \, NUL, control chars
  assertSafeRelativePath(name);               // throws on any escape sequence
  // safe to join with your storage root now
});

#5 — XML external entity (XXE)

The cleanest defense against XXE is not parsing XML. Daloy doesn't. If your domain forces you to, the framework doesn't silently help — which is the right kind of unhelpful.

#6 — Insecure deserialization

// JSON parsing in DaloyJS strips dangerous keys before they reach
// your handler. There is no flag for this; it is the constructor.
new App();

// Posting this body:
//   { "__proto__": { "isAdmin": true }, "constructor": { "prototype": {} } }
//
// reaches your handler as:
//   { }
//
// The discarded keys are logged at debug level. The empty schema
// validation result speaks for itself — your code never sees them.

#7 — Shell / command injection

#8 — Local file inclusion (LFI)

#9 — Prototype pollution

#10 — Open redirects

This is the one I had to actually ship. Before 0.35.0, if you wanted to redirect from a Daloy handler you wrote something like:

// 0.35.0 — fine if `next` is a hard-coded string,
// open-redirect bait if it came from a query parameter.
return new Response(null, {
  status: 302,
  headers: { Location: next },
});

That puts a load-bearing security decision on the developer at the latest moment in the stack. We have a verb for that: insecure default. So I wrote the missing helper, and gave it the only defaults that make sense — refuse on bad input, fallback if you ask for one, no implicit allow-list:

// src/routes/login-callback.ts
import { safeRedirect } from "@daloyjs/core";

app.get("/login/callback", (ctx) => {
  // `?next=` is attacker-controlled. Never trust it.
  const next = new URL(ctx.request.url).searchParams.get("next") ?? "/";

  return safeRedirect(next, {
    allowedPaths: ["/", "/dashboard", "/account"],
    allowedOrigins: ["https://app.example.com"],
    fallback: "/",        // bad input lands here instead of throwing
    // status defaults to 303 (See Other) — POST-redirect-GET-safe.
  });
});

// Things this refuses, by design:
//
//   /login/callback?next=//evil.com               -> protocol-relative
//   /login/callback?next=/\evil.com               -> backslash bypass
//   /login/callback?next=javascript:alert(1)      -> scheme-not-allowed
//   /login/callback?next=https://evil.com         -> origin-not-allowed
//   /login/callback?next=/ok%0d%0aSet-Cookie:pwn  -> control characters

The helper is a small, self-contained module — no framework internals, no dependency on App or Context. You can use it from a handler, from a hook, from a custom adapter, even from a script. The validation rules are tested in tests/safe-redirect.test.tsand cover every bypass the article mentions plus a few it doesn't: backslash-prefixed paths, CR/LF response-splitting payloads, scheme spoofing, unparseable absolute URLs, and unsafe fallbacks (yes, the helper also refuses a fallback that is itself an open-redirect bait).

The honest scoreboard

Against Aikido's top 10: nine were already covered, one (#10) was a real gap and now isn't. The shared-responsibility line stays where it always was — the framework gives you the primitives and the defaults, and you don't get to claim you were "just writing a redirect handler" anymore.

If you're upgrading, safeRedirect is exported from the package root:

import {
  safeRedirect,
  OpenRedirectBlockedError,
  // types
  type SafeRedirectOptions,
  type SafeRedirectStatus,
  type SafeRedirectBlockReason,
} from "@daloyjs/core";

Related reading on this blog: Secure by Default, Cloud Security Architecture, Mapped to DaloyJS, Vibe Coding Security, CSRF in 2026. Or jump straight to /docs/security/fetch-guard and /docs/security/owasp-api-top-10.