Forms started failing CSRF verification the moment I put a reverse proxy in front of the app

The check that is failing is origin comparison, and the proxy broke it by changing what the application sees.

CSRF protection on a form post compares where the browser says the request came from — the Origin or Referer header — against where the application believes it is running. That second value is assembled from the request: the host header and whether the connection was secure.

Behind a proxy, the browser talks HTTPS to the proxy and the proxy talks plain HTTP to your app. So the application sees an unencrypted request and concludes it is running at http://..., while the browser reports an origin of https://.... The strings differ, and the request is rejected.

That is why nothing you changed in the form matters, and why it appeared exactly when the proxy did.

The fix has two halves and both are needed.

On the proxy: forward the original request details. Pass the headers that say what the browser actually asked for — the original host, the original protocol, and the client address. Most proxies have a standard block for this and it is one of the first things to add to any proxy configuration.

In the application: trust them. Frameworks do not honour those headers by default, and that default is correct — anyone could send them if the app is reachable directly. You explicitly enable the setting that reads the forwarded protocol, and you list the origins you trust for CSRF purposes, with scheme, as full URLs.

The security caveat that comes with it: once the app trusts those headers, it must not be reachable except through the proxy. If both are true — app trusts the header, app is directly reachable — anyone can claim to be on HTTPS. Bind the app to localhost or to an internal interface.

Two more that produce the same rejection and are worth checking before rewriting the proxy config.

The cookie is not coming back. If the CSRF cookie is marked secure and something in the chain is still plain HTTP, the browser will not send it, and a missing token reads as a failed check. Look at the request in developer tools and confirm the cookie is actually on the submission.

Host mismatch. If people reach the site by more than one name — with and without www, a bare address, an internal name — each is a distinct origin and each needs to be in the trusted list, or better, redirect them all to one canonical name.

The canonical redirect is the fix I would reach for. Multiple valid entry points cause this class of problem repeatedly, and not only for CSRF.

One debugging shortcut that saves a lot of guessing: log what the application thinks the request scheme and host are, on one request, temporarily.

Every discussion of this ends up being an argument about what the app sees, and the app can simply be asked. Print the effective scheme, host and origin at the top of a view, submit one form, read the log, and you know immediately whether the proxy headers are arriving and whether the app is honouring them.