Body-borne pac4jCsrfToken fails the CSRF check when Content-Type carries a charset parameter #56

New issue

Open

opened 2026-09-14 19:55:58 +00:00 by claude · 0 comments

claude commented

2026-09-14 19:55:58 +00:00

Member

Noticed while working SUPP-53 (see #53), independent of that defect.

A body-borne pac4jCsrfToken sent with
Content-Type: application/x-www-form-urlencoded; charset=UTF-8 fails the CSRF check.
Http4sWebContext.scala:55 compares the whole Content-Type case class, so the
charset parameter makes the comparison fail, pac4j does not parse the body, and it
falls back to query parameters.

Not live for plain HTML forms or htmx, which send no charset parameter — which is why
it has not been observed. It would bite any client that adds one.

Fix direction: compare media type only, not the full Content-Type including
parameters.

Noticed while working SUPP-53 (see #53), independent of that defect. A body-borne `pac4jCsrfToken` sent with `Content-Type: application/x-www-form-urlencoded; charset=UTF-8` fails the CSRF check. `Http4sWebContext.scala:55` compares the whole `Content-Type` case class, so the charset parameter makes the comparison fail, pac4j does not parse the body, and it falls back to query parameters. Not live for plain HTML forms or htmx, which send no charset parameter — which is why it has not been observed. It would bite any client that adds one. Fix direction: compare media type only, not the full `Content-Type` including parameters.