In some web applications I have noticed there are to options set for X-Frame options header like
X-Frame-Options: DENY DENY
(DENY option should have been wrongly added twice).
In this case, will the browser obey to such header as it is obeying for
X-Frame-Options: DENY.
or else will it eliminate this header option as meaningless by considering "DENY DENY" as meaningless
if it is obeying, what will happen for scenarios like
X-Frame-Options: DENY SAMEORIGIN
Browsers handle X-Frame-Options: DENY DENY as if it were just X-Frame-Options: DENY.
Safari previously had a bug that caused it to ignore X-Frame-Options if it had a duplicate value, and Chrome inherited the same bug. And Firefox also previously had pretty much the same bug.
But they’ve since all been fixed: They behave the same as they would if the value was given once.
if it is obeying, what will happen for scenarios like
X-Frame-Options: DENY SAMEORIGIN
For that case, what Mozilla ended up implementing (and Safari and Chrome ended up following) is:
use the most restrictive policy… if the framing situation violates any of them, blocks the load
Thus the browser behavior for X-Frame-Options: DENY SAMEORIGIN is DENY (most restrictive).
So, unfortunately while there is no authoritative spec to point to on what the required behavior is if there are multiple values for the header—because the X-Frame-Options spec, RFC 7034 doesn’t actually state what the requirements are—in practice, the current Safari/Chrome/Firefox behavior is the expected behavior. Not sure what IE/Edge does, but if it’s different from Safari/Chrome/Firefox on this, then that’d be a bug that would need to be fixed in IE/Edge too.