Rails protects you against CSRF attacks, but it gives you a lot of customisation on how you want to react to them. It can be a great thing as you can have your own strategies, but it can also lead to security issues.

Marc G Gauthier

Rails provides three built-in CSRF protection strategies via `protect_from_forgery`: `exception` (raises an error and halts execution), `null_session` (nullifies the session but lets the request through), and `reset_session` (resets the session but also lets the request through). A key security gotcha is that only the `exception` strategy actually blocks fraudulent requests — the other two allow them to proceed with an empty session, which can be a serious vulnerability. The post also walks through building a custom forgery protection strategy by implementing a class initialized with a controller and responding to `handle_unverified_request`, enabling custom logging or fallback behavior.

Understanding Rails' Forgery Protection Strategies

The Different Forgery Protection Strategies