Middleware
Functions that sit between an incoming web request and the code that answers it, each able to inspect, change, or end the request, chained in an order that quietly determines how the whole application behaves.
In web frameworks, middleware is code that runs between the arrival of a request and the handler that produces the response. Each piece receives the request, can examine or modify it, and then either passes control to the next piece or ends the exchange itself. Chained together, middleware forms a pipeline that every request travels through.
The pattern handles concerns that apply across many routes and don't belong in any one of them:
- Logging and request timing.
- Sessions and authentication, loading the current user from a cookie or token; see Session Management.
- Security headers, cross-origin rules, and CSRF tokens; see Cross-Origin Resource Sharing and Cross-Site Request Forgery.
- Rate Limiting, rejecting clients that send too much.
- Compression of the response body.
Python's WSGI specification of 2003 described middleware as a component that looks like a server to the application and like an application to the server. Ruby's Rack, from 2007, popularized the idea of stacking such components, and Node's Connect and Express, from around 2010, made a three-argument function the familiar shape: the request, the response, and a function called next that hands off to the following step. Later frameworks such as Koa used async functions so each middleware wraps everything after it, running code both before and after the inner layers like the layers of an onion.
The design is function composition. Each middleware wraps a handler and returns a new handler, so the stack is built from higher-order functions. It closely resembles the chain of responsibility design pattern, in which a request passes along a series of objects until one handles it.
Order is behavior. Authentication placed after the route handler protects nothing. Compression applied before a component that rewrites the body corrupts it. Error-handling middleware must sit where it can catch failures from everything inside it. Since the order lives in configuration rather than in the code of each route, bugs of this kind are easy to introduce and hard to spot.
Middleware also moves logic out of view. A handler that assumes a user is present depends on something configured elsewhere. In 2025 a vulnerability in the Next.js framework let attackers skip its middleware entirely by sending a header the framework used internally, bypassing any authorization checks implemented there. Defense in depth means checking permissions near the data, not only at the edge of the pipeline.
The same idea appears outside application code. Proxies and gateways apply middleware-like steps before requests reach any server, and platforms now run middleware at the network edge; see Reverse Proxy and API Gateway.
Linked from6
- API GatewayNetworks & Distribution
An API gateway is the single front door to a set of backend services, handling cross-cutting policy once instead of per-service.
- Cross-Origin Resource SharingWeb Platform
The mechanism by which a server opts in to letting scripts on other origins read its responses.
- Higher-Order FunctionComputation & Algorithms
A function that takes another function as an argument, returns one, or both.
- LoggingTesting & Verification
Recording timestamped events from a running program so people can reconstruct what happened, and how structured logs, levels, and aggregation make them useful at scale.
- Rate LimitingNetworks & Distribution
Rate limiting caps how often a client can act, protecting shared capacity by rejecting or delaying the excess.
- Reverse ProxyNetworks & Distribution
A server that sits in front of other servers and receives clients' requests on their behalf, handling encryption, routing, caching, and protection in one place.