trillium-cors

By default a browser will not let a page read a response from a different origin than the page itself. This handler is how a server says which origins it will make an exception for, implementing the Fetch standard's CORS protocol.

Mount it ahead of the rest of the application. It answers the OPTIONS preflight a browser sends before any request that isn't a plain GET, HEAD, or form POST, and it adds the headers that let a page read the response to the requests that follow.

Example

use trillium_cors::Cors;
use trillium::Method;

let app = (
    Cors::allow_origins(["https://app.example.com"])
        .allow_methods([Method::Get, Method::Post, Method::Delete])
        .allow_headers(["content-type", "authorization"])
        .max_age(std::time::Duration::from_secs(600)),
    "hello from an api",
);

The browser is the enforcement point

CORS is not a server-side access control. A request from an origin this handler does not allow still runs; what the browser withholds is the page's ability to read the response. A disallowed origin is answered normally minus the CORS headers, and a request with no Origin header passes through untouched, which is what keeps non-browser clients working. reject_disallowed_origins() trades that for a 403.

Anything that must actually be denied — authentication, authorization, CSRF — needs a handler that enforces it, whether or not this one is present.

WebSockets

Browsers do not apply CORS to the WebSocket handshake; RFC 6455 assigns that check to the server, which has to compare the Origin header itself. This handler does not cover it, and adding it to an application will not protect a WebSocket endpoint.

Safety

This crate uses #![forbid(unsafe_code)].

License