v7.5.0: each app gets its own smaller pipeline, and a fix for sub-apps sharing one SecurityConfig

[rennf93]

pip install -U fastapi-guard

That pulls guard-core 3.10.0 with it. Your config, your decorators, your middleware setup all keep working unchanged.

The short version

guard-core 3.10.0 stopped running security checks that your configuration can never trigger. A default setup went from 17 checks per request to 4.

This release is the FastAPI side of that, plus one security fix that only became a security fix once the pipeline got smaller.

The security fix, first

If two SecurityMiddleware instances share the same SecurityConfig object, they used to share a pipeline. That is the documented sub-app mounted-middleware pattern, so it is not an exotic setup.

That was harmless while every app got the same 17 checks. It stopped being harmless the moment the pipeline started depending on which routes you decorated.

Concretely: app A decorates a route with @rate_limit. App B decorates one with @require_auth. They share a config. App A initializes first, builds a pipeline with no authentication check because none of its own routes need one, and registers it. App B starts, finds the cached state under the same key, adopts it by reference, and serves /needs-auth without ever authenticating anything.

The registry is now keyed on the config and the decorator handler together, so two apps with different decorators build their own pipelines. There is a regression test that fails against the old key.

You are affected if you mount sub-apps and pass the same SecurityConfig instance to more than one SecurityMiddleware. If you build a fresh config per app, you were never exposed.

Register your decorators and you get the smaller pipeline

Six checks depend entirely on your route decorators: authentication, referrer, time_window, required_headers, custom_validators, request_size_content.

guard-core can only skip them if it can see your route configuration. Before this release it could only see it if you called set_decorator_handler. Now it also picks up app.state.guard_decorator:

app.state.guard_decorator = guard_decorator

All three startup paths handle it: guard_lifespan, make_lifespan, and guard_startup.

If it cannot find your decorator handler at all, it assumes every route uses everything and keeps all six. You lose the speed, never the protection.

Check what you actually got. The middleware logs it at startup:

Security pipeline initialized with 5 checks: ['route_config', 'ip_security',
'rate_limit', 'suspicious_activity', 'authentication'] (12 skipped)

Two smaller changes

A request whose ASGI scope is not a real mapping no longer corrupts pipeline construction. It leaves the decorator handler unset rather than feeding a bogus value into the build. Mostly this bit test doubles, but a non-standard request object would have hit it too.

httpx2 is now a dev dependency, because that is what starlette's TestClient expects. Runtime dependencies are unchanged.

If you upgraded and something looks different

The pipeline log line will show fewer checks than you are used to. That is the point. Compare the skipped ones against your config: if a check you actually configured is missing from that list, that is a bug and I want to hear about it.

Full changelog: https://github.com/rennf93/fastapi-guard/blob/master/CHANGELOG.md

guard-core 3.10.0 release notes, which cover the pipeline change itself: rennf93/guard-core#61