How is the order of Servlet Filters determined, and why does order matter?

### Why ordering is even a question Servlet Filters form a **Chain of Responsibility**: each filter runs, optionally calls `chain.doFilter` to invoke the next, and optionally runs code after that call returns. Because the calls are **nested** (filter A calls B which calls C which calls the servlet, then unwinds back through C, B, A), the *order* in which filters are placed determines: - which filter sees the request **first** (outermost), - which filter sees the response **last** (also the outermost, on the unwind), - and which filters get a chance to **short-circuit** (reject/redirect) before later ones run. ### How order is configured There are several configuration mechanisms, and they decide order differently: **1. `web.xml` (the classic deployment descriptor).** You declare `<filter>` elements (the definitions) and `<filter-mapping>` elements (which URLs each applies to). The **order of the `<filter-mapping>` elements** in the file determines execution order. The spec also says URL-pattern mappings are applied before servlet-name mappings. This is fully deterministic. **2. `@WebFilter` annotation.** You annotate a class with `@WebFilter("/path")` and the container discovers it. The Servlet spec does **not** define a relative order among annotation-discovered filters — it is implementation-dependent. So if order matters, annotations alone are risky. **3. Programmatic registration (Spring Boot).** You register a filter as a `FilterRegistrationBean` and call `setOrder(int)` — **lower numbers run earlier**. Alternatively a `Filter` bean implementing `Ordered` or carrying `@Order` is ordered by the framework. This is the recommended approach when order is important, because it is explicit and centralized. ### Key terms - **Deployment descriptor (`web.xml`)**: an XML file declaring servlets, filters, and mappings. - **`FilterRegistrationBean`**: a Spring Boot object that wraps a filter and exposes URL patterns and an `order`. - **`@Order` / `Ordered`**: Spring's general ordering mechanism; lower value = higher priority = runs first. - **Short-circuit**: a filter ending the request (not calling `chain.doFilter`) so later handlers never run. ### Why order matters — concrete cases - **Security before business**: an authentication filter must run *before* any filter or servlet that assumes a logged-in user; if it runs too late, an attacker may reach protected logic. - **Decode before parse**: a filter that decompresses or sets character encoding must run before one that reads/parses the body, or the body is read in the wrong form. - **Logging placement**: a logging filter placed outermost (first) sees the untouched request and the fully-built response; placed innermost it misses what other filters changed. - **Wrapping**: filters that wrap the request/response (e.g. to cache the body) must enclose the filters that depend on the wrapper. ### Spring Security note In a Spring app, **Spring Security registers a single `DelegatingFilterProxy` / `FilterChainProxy`** into the servlet chain, and *inside* it runs its **own** ordered chain of security filters. So there are effectively two levels of Chain of Responsibility, and the position of that one security filter within the servlet chain still matters. ### Failure modes of bad ordering Leaking unauthenticated access, double-compressing a response, logging a request that a later filter then rewrites, or a wrapper filter not enclosing its dependents. Each is a direct consequence of the nesting order — which is why ordering is treated as part of the chain's contract, not an afterthought.