ServiceNow / Security - Is it a risk to disable a "X-Frame-Options HTTP response header" property?

[david_legrand]

I have a customer who would like to know the "practical consequences/risk" of deactivating a property in ServiceNow.

The property glide.set_x_frame_options is saying:

Enable this property to set the X-Frame-Options response header to SAMEORIGIN for all UI pages. The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. https://developer.mozilla.org/en/the_x-frame-options_response_header

I would like to know if someone with a great Security knowledge (better than me anyway) a short explanation like "If you disable this property and if I know ****, I'll be able to do *** even if I have no rights to do it" and/or a short summary like "Do not do that, fool" or "It isn't a best practice but it's possible to do, the consequences won't be huge".

Regards,

ps:I can give points to helpful and correct answers (and my gratitude)

ps2: I also asked my fellow colleagues who work on Security purpose, if I have an answer from them, I'll publish it here

[justin_drysdale · Accepted solution]

An attacker could embed your page into their own page.   The attacker can then make your page elements do different (malicious) things.   The end user thinks the page is legit because hey, it looks legit! The end user may click on elements like usual only to have malicious scripts/elements/thingies run.

It is mostly to fool the end user into running what the attacker wants.   You most likely don't want a user to see/use 'your' page and get malware, or maybe even worse, have a browser alert show the 'possible clickjacking attempt' message.

[david_legrand]

Thank you very much for your answer, so I don't want to do that

[ywen]

even if you're able to load the iframe in a parent page, JS logic from a malicious parent page is not able to access or modify the contents within the iFrame, per the same origin policy that is enforced by the browser's JS engine.