actix-csrf

CSRF middleware for [actix-web] 4.0.0 or newer that uses the Double-Submit Token pattern.

This crate has not yet been audited. Use in production at your own risk.

Usage

Installing the middleware is standard: Specify a cryptographically secure RNG to use, and declare which paths should set a CSRF cookie and when should validate a CSRF cookie.

```rust

[actix_web::main]

async fn main() -> std::io::Result<()> { HttpServer::new(|| { let csrf = Csrf::::new() .setcookie(Method::GET, "/login"); App::new().wrap(csrf).service(loginui).service(login) }) .bind(("127.0.0.1", 8080))? .run() .await } ```

Then, use the CsrfCookie extractor to pull the CSRF cookie and validate it with a CSRF token provided as part of the protected request.

```rust

[derive(Deserialize)]

struct LoginForm { csrf_token: CsrfToken, username: String, password: String, }

impl CsrfGuarded for LoginForm { fn csrftoken(&self) -> &CsrfToken { &self.csrftoken } }

/// Validates a login form that has a CSRF token.

[post("/login")]

async fn login(form: Csrf>) -> impl Responder { // At this point, we have a valid CSRF token, so we can treat the request // as legitimate.

HttpResponse::Ok().finish()

} ```

This is only one of many ways to use the Double-Submit Token pattern; see the [docs] and examples for more information.

Security Considerations

There are advantages and limitations to using the Double Submit Token pattern. Users are highly recommended to read the Owasp article on CSRF Protection before using this middleware.

This crate attempts to have secure defaults, and users must explicitly disable defense-in-depth features.

License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.