prevent loss of frame_src/child_src when using append_content_securit…

[bobjflong]

…y_policy_directives

Currently it is possible for frame_src and child_src settings to be dropped when using append_content_security_policy_directives.

To reproduce:

1. Set a frame_src
2. Override the child_src using append_content_security_policy_directives
3. Load the headers using a browser that will receive child_src from secureheaders, such as Chrome

Expected: the child_src is defaulted to the frame_src setting I have, plus the additions I made using append_content_security_policy_directives. I have this expectation because the gem promises to intelligently select between child_src and frame_src.

Actual: In this case, the original frame_src settings are dropped, and the child_src setting is default_src + my additions.

All PRs:

• Has tests
• Documentation updated

[bobjflong]

If this is merged, it would actually be worthwhile updating the docs to explain that append_content_security_policy_directives can now pick defaults from frame_src or child_src.

[oreoshake]

You should never be setting child-src AND frame-src, always one or the other. The idea behind the code is that you could use either or and, based on the user agent, the lib would set the appropriate value. However, this code has definitely rotted.

That being said it's not communicated in any way and has created this issue. I wonder if we should just 🔪 child-src entirely? I'll have to double check but as far as I remember, they are interchangeable and should only produce console warnings on outdated browsers.

[bobjflong]

Yes to be clear - I'm not suggesting setting both, I'm suggesting that setting one and calling append_content_security_policy_directives with the other causes the bug. However I can understand not wanting to add more logic to a confusing situation.

[oreoshake]

Yep, thanks! I'll probably merge this in to prevent the confusion you exposed, I was just thinking out loud and more long term.

Thanks again for all the 👀 and 💻 ❗️