Open rzhade3 opened 1 month ago
This means that if a user is trying to change some framing functionality, and only changes the XFO header, they might be confused as to why the functionality didn't actually change.
The override approach/mechanism wouldn't change, right? Just that they need to override both, correct?
Also, FWIW, I am for the :whynotboth:
approach and the lack of a frame-ancestors
default bothered me slightly.
We should consider setting a default
frame-ancestors
directive for the Content Security Policy. Theframe-ancestors
directive is the new iteration of the X-Frame-Options header, and as such setting a directive in both spots might be prudent.https://github.com/github/secure_headers/blob/b134eef07d3741b4bd0769b863961b41af5df57d/lib/secure_headers/headers/content_security_policy_config.rb#L97
Since our default XFO policy is
sameorigin
, if we decide to take upon this task, we should set the defaultframe-ancestors
value to beself
.Some counterpoints: setting both the
X-Frame-Options
and theframe-ancestors
directive will cause the XFO header to be overriden by the frame-ancestors directive. This means that if a user is trying to change some framing functionality, and only changes the XFO header, they might be confused as to why the functionality didn't actually change.