aikido zen fails with express middleware order error, routes unprotected

Not specified by the original author.

TL;DR: If you installed Aikido Zen and attacks are showing up in your dashboard but nothing is actually blocked, that is the default: Zen detects and reports but does not block until you set AIKIDO_BLOCK=true in the environment.

Fix

1. If you installed Aikido Zen and attacks are showing up in your dashboard but nothing is actually blocked, that is the default: Zen detects and reports but does not block until you set. Expected: this specific failure stops.

2. must be the very first import, above everything else, or the instrumentation misses modules loaded earlier; (2) if you want per-user rate limiting or user blocking, call. Expected: this specific failure stops.

Details

AIKIDO_BLOCK=true in the environment. The docs recommend running with blocking enabled on staging for about a week before turning it on in production, so you can tune out false positives first. Two related setup points from the same docs: (1) import aikido_zen / require('@aikidosec/firewall') set_user({"id", "name"}) from your auth middleware as soon as the user is identified, otherwise Zen only sees IPs.

When to use

You hit exactly this: Zen does not block attacks by default; set AIKIDO_BLOCK=true to actually stop them in Zen.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Zen.

Documented gotcha from official Aikido Security docs: Official docs (Aikido firewall-python docs/fastapi.md, github.com/aikidosec/firewall-python): documents the gotcha that Zen runs in non-blocking mode by default. When it detects an attack it reports it to Aikido and lets the call continue executing, so attacks are logged but not stopped unless you opt in. The verified fix/answer: If you installed Aikido Zen and attacks are showing up in your dashboard but nothing is actually blocked, that is the default: Zen detects and reports but does not block until you set AIKIDO_BLOCK=true in the environment. The docs recommend running with blocking enabled on staging for about a week before turning it on in production, so you can tune out false positives first. Two related setup points from the same docs: (1) import aikido_zen / require('@aikidosec/firewall') must be the very first import, above everything else, or the instrumentation misses modules loaded earlier; (2) if you want per-user rate limiting or user blocking, call set_user({"id", "name"}) from your auth middleware as soon as the user is identified, otherwise Zen only sees IPs. Source: https://github.com/aikidosec/firewall-python/blob/HEAD/docs/fastapi.md

Not specified by the original author.

TL;DR: auth.protect() never fires for your API routes because the middleware never runs there. curl with no cookie gets real data. The middleware looks correct, but it never executes for /api paths. Confirm the cause 1.

The fix

1. Read the exported config.matcher in your middleware file. If the patterns exclude api routes, the middleware skips them entirely.
2. Reproduce with curl against a protected API route with no session cookie. If you get data instead of a 401 or redirect, the middleware is not running there.
3. Include the API pattern in the matcher alongside the page pattern. The page pattern skips Next.js internals and static files; the second entry makes sure the middleware always runs for API routes:
4. Add defense in depth: call auth() inside the route handler too and return 401 when there is no userId. Middleware is one layer; the handler check is the second.

When to use this

• This covers exactly what the title says: API routes wide open to unauthenticated callers.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with API; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current API behavior.

Verified against Clerk middleware guides 2026-09-26: the standard matcher config pairs the static-asset-skipping regex with '/(api|trpc)(.*)' so the middleware always runs for API routes.

Not specified by the original author.

TL;DR: A route you assumed was protected is reachable signed-out. The middleware lists protected paths, so every route you add later is public by default until someone remembers to list it. Confirm the cause 1. Read your middleware.

The fix

1. Read your middleware. If it says if (isProtectedRoute(req)) { await auth.protect() } with a list of protected paths, you have an allowlist. New routes are born unprotected.
2. Audit: pick three routes you believe are protected and request them with no session. Any 200 on a page that should require auth confirms it.
3. Invert the check: list only public routes, protect everything else.
4. After inverting, re-audit the same three routes plus every route added in the last month.
5. Keep server-side auth() checks inside route handlers and server components as a second layer; the middleware is not the only gate.
6. This covers exactly what the title says: New pages silently unprotected.
7. You are setting this up for the first time, or auditing an existing setup.
8. You want the key gotchas in one place before you start.
9. You are doing a different workflow with New; these steps are specific to the title above.
10. You need the full reference docs; this is the short path, not the manual.
11. Not pinned to a specific version; follows current New behavior.

When to use this

• This covers exactly what the title says: New pages silently unprotected.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with New; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Verified 2026-09-26: a Clerk middleware advisory record documents this exact shape, naming the isProtectedRoute allowlist as the bypassable pattern and the inverted isPublicRoute check as the correct one, with server-side auth() checks as defense in depth.