Identifying iframe-unfriendly sites in rails — even when x-frame-options is missing from header -

background:

i'm working on rails app open articles inside app via iframe (with navbar @ top app, kind of stumbleupon). i've noticed websites publish articles (examples: pitchfork.com, vox.com, theverge.com) prevent being loaded in iframe setting x-frame-options sameorigin or deny.

my current plan work around @ header link , examine see if contains x-frame-options. if so, set forego iframe , open original site in new tab.

this method seems work websites (like pitchfork.com) because when request header pitchfork.com, following:

server: nginx/1.4.6 (ubuntu) content-type: text/html; charset=utf-8 x-frame-options: sameorigin date: wed, 27 jan 2016 17:47:54 gmt x-varnish: 912263733 912263044 age: 8 via: 1.1 varnish connection: keep-alive 

problem:

for websites (like vox.com), when load them in iframe, the chrome developer console tells me x-frame-options preventing site loading in iframe. when examine header, x-frame-options found! this:

server: nginx/1.6.2 date: wed, 27 jan 2016 17:26:15 gmt content-type: text/html content-length: 172 connection: close 

how vox.com doing this? further clarification, tried using this tool found in stackoverflow post , failed correctly detect vox.com blocking iframes via x-frame-options.

1) vox able set x-frame-options somewhere other header? if latter, how can detect , find that?

2) other alternate strategies recommend detecting iframe-unfriendly sites can have them set open in new tab instead?

take @ network traffic recorded in chrome console. in app, you're looking @ headers of http 301 moved permanently response, redirects location return x-frame-options: sameorigin header.

other methods, such newer content-security-policy header or javascript code, may used other websites prevent iframe embedding. in case of vox.com, you're looking @ headers of wrong response.