Be careful of ForwardedHeaderFilter.
Don't use it with Jetty and Jetty's default ForwardedRequestCustomizer.
They essentially do the same thing, but the Filter + Wrapping approach isn't 100% compatible with 100% of requests (external and internal).
I would recommend using the ForwardedRequestCustomizer only, as it does the correct changes to your Request before the Request even reaches your ServletContext.
That way it will work on all requests, even internal dispatched ones, request logging, and even on error handling (inside and outside of your ServletContext).
Having both DoSFilter and QoSFilter in the same chain is unusual (but not impossible, nor problematic)
DoSFilter is typically used to control all requests on all url-patterns.
QoSFilter is typically used to control slow behavior on specific url-patterns that are known to take too much time. (like big database queries)
DoSFilter is the sledgehammer, QoSFilter is the scalpel.
If you DoSFilter, there's very little need for QoSFilter. (you are covered)
And if you understand your webapp well enough to use QoSFilter properly, there's not much need for DoSFilter.
As for where Spring Security should sit in the chain...
Most people protect all components that have external access (like a LDAP server) on their webapp when selecting to use DoSFilter or QoSFilter.
If your Spring Security has an external system dependency, then protect it too.
