I'm facing a scenario where there are bad actors POST-ing JSON at sensitive (logged out) endpoints at high scale.
In addition to rate limiting by IP, I would like to add protect_from_forgery with: :exception as a before_filter to the Rails app.
Does that filter return a 500 response or actually raise an uncaught exception that crashes the Rails process? Locally, it appears to be the latter.
My concern is that unauthenticated bots would effectively DDOS the service by crashing processes repeatedly.
No, all uncaught exceptions in your app should be rescued by Rails (or Rack) and logged, with a 500 error being returned to the client. Only a segfault or other critical failure would cause the process to die. And even in such cases, a good webserver (say, Puma) will restart the process. But if even Puma manages to die, your production environment should have a process monitor (god, monit, etc) which will restart the web server if it fails or exceeds memory bounds.
I'm curious what you mean by "locally, it appears to [crash the Rails process]". Your command of rails server is actually exiting upon a CRSF exception?