Open jmcampanini opened 8 years ago
Why is this part of the security bundle?
there seems to be sufficient security implications to not having these headers properly set:
considering the security implications and that the majority of our services are already setting this with one-off filters makes me think that it's common security-related code that fits within the context of the web-security bundle.
Lets discuss offline, maybe there is something I'm not entirely understanding here because I don't see why the defaults built into Jetty aren't sufficient.
discussed offline. will come back to this later and investigate a better caching strategy for our apps in general. at this point, there is no pressing need as each application is handling this on their own.
@jmcampanini can I close this?
Hi, Any plans of adding the Cache-Control and Pragma headers to the doordeck/dropwizard-web-security project? Lack of these headers shows up as a vulnerability in scans. (Though it is low priority)
Dropwizard does ship with a native @CacheControl
annotation at https://www.dropwizard.io/1.3.9/docs/manual/core.html#caching, if that helps.
Thanks @jplock for the pointer. However, it would be good to have a single global place to do this. Have a lot of resource files and functions and it would be difficult to annotate all of them.
consider adding cache headers. an example of this (and rationale) can be found here: Spring Security Cache Controls.
the goal would be to add these headers only if they haven't already been set. this would allow servlets to still define their caching functionality.
the proposed implementation would be to:
Cache-Control
orPragma
header is set, do not set anythingthis will follow the same priority for configuration as the rest of the bundle (high to low): YAML > coded values > default values of bundle.
the headers and their default values:
// tagging for SA: @qinfchen @derekcicerone @jlz27 @rcchen