[openstack-dev] [cinder][security][api-wg] Adding http security headers
doug at doughellmann.com
Thu Jul 5 17:17:58 UTC 2018
Excerpts from Jim Rollenhagen's message of 2018-07-05 12:53:34 -0400:
> On Thu, Jul 5, 2018 at 12:40 PM, Nishant Kumar E <
> nishant.e.kumar at ericsson.com> wrote:
> > Hi,
> > I have registered a blueprint for adding http security headers -
> > https://blueprints.launchpad.net/cinder/+spec/http-security-headers
> > Reason for introducing this change - I work for AT&T cloud project –
> > Network Cloud (Earlier known as AT&T integrated Cloud). As part of working
> > there we have introduced this change within all the services as kind of a
> > downstream change but would like to see it a part of upstream community.
> > While we did not face any major threats without this change but during our
> > investigation process we found that if dealing with web services we should
> > maximize the security as much as possible and came up with a list of HTTP
> > security headers that we should include as part of the OpenStack services.
> > I would like to introduce this change as part of cinder to start off and
> > then propagate this to all the services.
> > Some reference links which might give more insight into this:
> > - https://www.owasp.org/index.php/OWASP_Secure_Headers_
> > Project#tab=Headers
> > - https://www.keycdn.com/blog/http-security-headers/
> > - https://securityintelligence.com/an-introduction-to-http-
> > response-headers-for-security/
> > Please let me know if this looks good and whether it can be included as
> > part of Cinder followed by other services. More details on how the
> > implementation will be done is mentioned as part of the blueprint but any
> > better ideas for implementation is welcomed too !!
> Wouldn't this be a job for the HTTP server in front of cinder (or whatever
> service)? Especially "Strict-Transport-Security" as one shouldn't be
> enabling that without ensuring a correct TLS config.
> Bonus points in that upstream wouldn't need any changes, and we won't need
> to change every project. :)
> // jim
Yes, this feels very much like something the deployment tools should
do when they set up Apache or uWSGI or whatever service is in front
of each API WSGI service.
More information about the OpenStack-dev