Remove X-XSS-Protection header about docker-php HOT 13 CLOSED

ENV CONTENT_SECURITY_POLICY='{ "some": "JSON" }'

💡 Then use jq to turn it into a HTTP header.

from docker-php.

@danpastori You should review this above. ☝️

I'll probably pull this in the next release if you are cool with it.

from docker-php.

@jaydrogers Makes sense to remove it. Looks like it's kind of a "false security" that can be circumnavigated through other attempts. We've implemented a secure CSP on our Docker containers right?

from docker-php.

We did, but then we removed it 😁

from docker-php.

Adding more comments from /u/Tontonsb:

I just read the discussion on your PR. Yeah, CSP is the only solution, but unfourtunately it's complex and very project specific. And on legacy projects you're just sometimes left with default-src https: data: 'unsafe-inline' 'unsafe-eval'... Actually, not "legacy" projects, but normal projects that are not made with CSP in mind.

We might want to remove CSP all together and let users manage it on their own, or come up with a way where it can be easily managed with an environment variable 🤔

It gets very project specific and we will need really good documentation on this.

from docker-php.

Just thinking out loud. How hard would it be to add some sort of custom .env type file that gets compiled into docker that's set on a per-app basis? For example (I'll try my best at yml):

Headers
     CSP
          "default-src"
          'self'
          http:

And then you just flatten that array to be the header that gets added. I know when working with Electron and CapacitorJS, you have to have this down to a science.

from docker-php.

As an appending to ☝️, are there any other settings that would be useful to store in an env that are app specific? Maybe you already have this.

from docker-php.

Good news is, there is no YAML in this repo. 🤓

ENVs are set like this:

So that means it would look like this:

ENV CONTENT_SECURITY_POLICY="\"default-src \'self\' http: https: data: blob: \'unsafe-inline\'\" always\;"

☝️ But as you can see, I don't even know if this example will work.

We would have to escape all of this stuff in bash, which might get really messy. Not sure how NGINX would take this.

Thoughts?

from docker-php.

I'm thinking about providing an optional "App Specific" env. Would that make sense? Some sort of config file that you could customize and build into the docker image to overwrite values, or add values on an app specific basis?

It could be completely out of scope since I can set some of the CSP stuff in HTML. Just thinking.

from docker-php.

That could definitely work. The only negative I see from controlling it from the app level for the ENV would be we need to figure that out for both application types:

1. Laravel
2. WordPress

Putting the ENV at the docker layer will allow us to set an ENV within Docker which could then be easily customized for any type of app.

from docker-php.

I wonder if @szepeviktor would have any thoughts on this? ☝️

from docker-php.

This speaks for itself. ~100% of browser makers do not support it.

I do not understand the technical details.
As far as I see security is made from very many steps. There is no way to protect a website without human 👨‍🔬 expertise and continuous presence: an expert webmaster.

from docker-php.

Thanks @szepeviktor!

Specifically, I was wondering if there is a sensible way to set the content security policy as an ENV without it looking like garbage with all of the escaping. See this comment for more details: #31 (comment)

from docker-php.