Align X-Frame-Options with CSP and add missing X-XSS-Protection header#597
Open
flightlesstux wants to merge 1 commit intopassbolt:masterfrom
Open
Align X-Frame-Options with CSP and add missing X-XSS-Protection header#597flightlesstux wants to merge 1 commit intopassbolt:masterfrom
flightlesstux wants to merge 1 commit intopassbolt:masterfrom
Conversation
Two issues in the SecurityHeadersMiddleware configuration: 1. setXFrameOptions() was called without an argument, which defaults to SAMEORIGIN. The comment above explicitly states 'Don't allow framing the site', and ContentSecurityPolicyMiddleware already sets 'frame-ancestors none' in the CSP. The X-Frame-Options header was inconsistently weaker than the declared CSP policy. Fix: pass 'deny' to match the intent and the CSP. 2. The comment 'Tell browser to block XSS attempts' was present but setXssProtection() was never called, leaving X-XSS-Protection absent from responses. While modern browsers rely on CSP over this legacy header, it provides defence-in-depth for older user agents. Fix: add ->setXssProtection() to the chain.
Member
|
Hi @flightlesstux ! Thank you for this pull request. This is interesting indeed. I think, yes, However, for the second one, I can't agree. It sounds good at first sight but when reading https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-XSS-Protection it feels like we should not go with this one. Plus according to the Browser compatibility section, this header is not supported anymore (the latest browser that supported it was Microsoft Edge in 2015). So, I would go for the Cheers |
Member
|
For information, it's now under review for a merge with the ticket |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Two inconsistencies in the
SecurityHeadersMiddlewareconfiguration inApplication::middleware():1. X-Frame-Options too permissive
setXFrameOptions()is called without arguments, which defaults toSAMEORIGIN. The comment directly above reads "Don't allow framing the site", andContentSecurityPolicyMiddlewarealready setsframe-ancestors 'none'in the default CSP — which prohibits all framing including same-origin.The
X-Frame-Optionsheader was weaker than the declared CSP policy, creating an inconsistency:Content-Security-Policyframe-ancestors 'none'X-Frame-Options(before)SAMEORIGINX-Frame-Optionsis the legacy fallback for browsers that don't support CSPframe-ancestors. It should match the stricter CSP intent.2. X-XSS-Protection never set
The comment block reads "Tell browser to block XSS attempts" but
setXssProtection()was never called. TheX-XSS-Protectionheader was absent from all responses.Fix
Impact
X-Frame-Options: DENYnow matches the CSPframe-ancestors 'none'policy across all browsers including those without CSP supportX-XSS-Protection: 1; mode=blockadded for legacy browser defence-in-depth