Module security 

Security response headers applied by default. See SecurityHeaders. Security response headers, applied to every response by default.

Most frameworks leave these to the application, which means most applications ship without them. Churust sends a conservative set unless told otherwise, and always yields to a handler that set the header itself.

“Every response” is meant literally, and that takes two mechanisms rather than one. Most responses come out of the pipeline, where SecurityHeadersMiddleware decorates them. A few do not: a body refused on its declared Content-Length before dispatch, the RFC 9112 §6.3 refusal, a request that outran request_timeout_ms so the pipeline never produced anything at all. Those are answered by the transport, and each transport applies the same set to whatever it is about to write — see App::apply_security_headers. Applying twice is deliberately harmless, because a header already present is left alone.

What is genuinely out of reach is a response Churust never composed: hyper answering 431 for a header block over max_headers, or a malformed request line that never became a request. Nothing in this crate sees those.

use churust_core::{Churust, SecurityHeaders};

// Customise:
Churust::server().security_headers(
    SecurityHeaders::new().referrer_policy(Some("strict-origin-when-cross-origin")),
);

// Or opt out entirely:
Churust::server().without_security_headers();

Structs

SecurityHeaders

Which security headers to add, and with what values.