Do I need a WAF if I already have security middleware?

It depends on your traffic profile. Middleware cannot absorb a volumetric flood — that traffic reaches your origin and consumes your compute. If you are a plausible target for volumetric attacks or run a public API at scale, you need the edge layer too. A small SaaS with ordinary traffic generally gets more risk reduction from middleware, because its real exposure is authorization and business-rule abuse, which no WAF can see.

Why can a WAF not stop broken access control?

A WAF has no session context. User A requesting their own invoice and user A requesting user B's invoice are both well-formed GET requests to the same route shape. Deciding which one is permitted requires knowing who is authenticated and what they may access, which is application state the edge never sees.

What breaks when both a WAF and middleware enforce the same control?

You get double enforcement with different thresholds. If the edge limits at 100 requests per minute and middleware at 60, users experience the tighter limit while your edge dashboard reports the looser one, and the discrepancy makes support tickets impossible to reproduce. Assign each control to exactly one layer.

Are WAF rules portable between providers?

No. Rules are written in each provider's rule language and stay with that provider. Migrating means re-deriving your posture from scratch, and because vendor rule sets are opaque, you often cannot state precisely what was being enforced. Policy expressed as code in your own repository moves with the application.

GUIDE · ARCHITECTURE · UPDATED 2026-08-29

WAF vs application middleware: where should your security boundary live?

This is usually argued as edge versus application. The more useful question is what information each layer has at the moment it decides — because that determines which attacks it can possibly catch.

The comparison is usually framed as edge versus application. The useful framing is what information each layer has when it decides.

	Edge WAF	Application middleware
Runs before your compute	Yes — bad traffic never costs you	No — you pay for every request it rejects
Sees who the user is	No — no session, no role, no plan	Yes
Sees whether the request is meaningful	No — a valid-looking request for someone else's data looks fine	Yes
Absorbs volumetric floods	Yes, at provider scale	No — the flood reaches your origin
Rules you can read and reproduce	Usually not — vendor rule sets are opaque	Yes — code in version control
Deploys with your application	No — separate console, separate change process	Yes — same pipeline, same review, same rollback
Survives a provider migration	No — rules are provider-specific	Yes, if the policy is portable

The asymmetry that decides most designs: a WAF cannot tell the difference between user A requesting their own invoice and user A requesting user B's invoice. Both are well-formed GETs to the same route shape. Authorization is application knowledge — no edge rule set will ever cover it.

What a WAF is genuinely good at

Volumetric attacks. Absorbing floods before they reach origin is exactly what edge infrastructure is for, and you cannot replicate it in middleware.
Known-signature payloads. Generic SQLi and XSS strings from commodity scanners get filtered without consuming your compute.
Emergency response. When a CVE lands in a dependency, an edge rule can block the exploit path in minutes while the real patch goes through your release process.
Coverage for what you forgot. Legacy endpoints and unmaintained services still sit behind it.

What only middleware can do

Authorization. Whether this session may perform this action on this object. Not visible from the edge, ever.
Business-rule abuse. Ten password resets for ten different accounts from one session is not malformed traffic; it is a pattern only your application can recognise.
Context-aware limits. Free tier gets one budget, enterprise another. The edge does not know which one is calling.
Testable rules. A rule you can unit test with fixtures, review in a pull request, and roll back with a deploy.

When running both is worth the cost

They are not alternatives. The question is whether you need both layers now.

Situation	Recommendation
Static site or brochure, no user accounts	Edge headers and bot rules are enough
SaaS with accounts, no unusual traffic volume	Middleware first; it covers the risks that actually apply to you
Public API with paying customers	Both — edge for volume, middleware for per-key budgets and authorization
Consumer product at scale, or a known target	Both, non-negotiable
Compliance requires documented WAF	Both, and keep the middleware rules as the ones you actually reason about

Running both introduces one recurring failure mode worth naming: double enforcement with different verdicts. When the edge rate limits at 100/min and middleware limits at 60/min, users hit the tighter limit but your dashboards show the looser one, and nobody can explain the support tickets. Decide which layer owns each control, and let the other one stay out of it.

The portability question

WAF rules are written in a provider's rule language and stay with that provider. If your security posture lives entirely in one vendor's console, changing providers means re-deriving it from scratch — and in the meantime nobody can tell you exactly what is being enforced, because the rule set is opaque by design.

Middleware rules move with the code. That is worth something when the same organisation runs sites on static hosting, a Node service and an edge runtime, and wants one answer to "what is our policy?" rather than three consoles to reconcile.

Where TJ Sentinel sits

TJ Sentinel is the middleware layer, deliberately. It does not try to be a WAF and cannot absorb a volumetric flood — that is stated plainly because a tool that overstates its coverage causes worse decisions than one that does not exist. What it provides is the portable half: one policy file, adapters for static hosting, Express, Next.js and Cloudflare Workers, and identical verdicts with the same reason codes across all of them. Run it behind whatever edge protection you already have.

Generate a policy for your site → · Read the stated limits →