Page MenuHomePhabricator

non consistent X-Frame-Options
Closed, InvalidPublic


The X-Frame-Options header delivered by Mediawiki (at least in Wikimedia servers) for same-origin request isn't consistent: sometimes allowing frames and sometimes deny, in unpredicted pattern.

I couldn't reproduce it in enwiki, but in hewiki I did, but only as a registered user (as anonymous user it isn't reproducible). As far as I tested it may be related to users right (my wgUserGroup is [bureaucrat,sysop,user, autoconfirmed] in hewiki, and [user, autoconfirmed] in enwiki).

How do I test it:

  1. get to some hewiki page (we don't want to do cross origin requests)
  2. peek some of diff from recent changes (it should be latest edit [that can be rolled back] or diff that hasn't been patrolled yet)
  3. add iframe to it $('ul:first').append($('<iframe src="DIFF" width="50" height="50"></iframe>')) - it fails (X-Frame-Options DENY)
  4. peek some non latest diff [that isn't possible to rollback]
  5. do the same - it successes (no X-Frame deny)

(Step3 always fails as registered, but success as anonymous)
I think it should be possible to reproduce the bug under different wikis if you have sufficient rights.

Specific example for DIFFs:

  1. non latest edit -
  2. latest edit -

I don't see a reason why same origin requests don't allow frames, but if there is some reason to do so - it should be consistent.

Version: 1.21.x
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:19 AM
bzimport set Reference to bz46560.
bzimport added a subscriber: Unknown Object (MLST).

I've been seeing something similar on enwiki while using
The tool displays a Wikipedia article in an iframe on the left. Most of the time it works fine, but every so often, the iframe is blank. When the iframe is blank, there is an error in the browser's error console: Refused to display '(url here)' in a frame because it set 'X-Frame-Options' to 'DENY'.
It doesn't seem to happen if I'm not logged in.

Its related to whether a page is "click-jackable". For ordinary articles, usually that means if there is a "patrol" link on the page.

I don't think this is a bug. This behaviour is configurable in LocalSettings.php by setting $wgBreakFrames = true;

Some might argue we should change the config either in wikimedia, or the default for mediawiki, but that should be a separate bug I think.