Clickjacking mitigation

I have tried to understand this several time, and found the issue difficult to grasp.   Here is my attempt to restate the threat, partly for documentation and partly to get feedback if I have it wrong:

• User gets tricked to a bad-guy site, which loads an invisible page which allows him to intercept everything the user clicks or types.
• The user then navigates to your site, which is loaded into the bad-guy site as included content.
• The user attempts to do something on your site, but the bad guy gets the click and intercepts it to do something different or something extra.

The headers are a workaround to prevent being embedded in the wrong places:

• Top-level pages should say "I should never be embedded in another web page".
• Embedded pages should say "I should only be embedded in specific sites", where the specific site can be "same server as this code" or a list of servers.

Then the browsers check to see if your content is embedded someplace where it does not belong.

Wikipedia says that X-Frame-Options is older while Content-Security-Policy is the newer, and fully standardized version.   The newer one is preferred but it is acceptable to use both to cover all bases.

From a web design standpoint, you need to know what stuff is embedded where, so it helps to have a development environment that helps you keep track of this stuff.

Not sure how big a risk this is, and it is technically not your problem.    You can probably use the UTM login page templates to add the header, but User Portal was not modifiable in 9.5.   Has that changed in 9.6?   And  you need to worry about whether the back-end WAF application complies with the policy and continues to assert it.

I have tried to understand this several time, and found the issue difficult to grasp.   Here is my attempt to restate the threat, partly for documentation and partly to get feedback if I have it wrong:

• User gets tricked to a bad-guy site, which loads an invisible page which allows him to intercept everything the user clicks or types.
• The user then navigates to your site, which is loaded into the bad-guy site as included content.
• The user attempts to do something on your site, but the bad guy gets the click and intercepts it to do something different or something extra.

The headers are a workaround to prevent being embedded in the wrong places:

• Top-level pages should say "I should never be embedded in another web page".
• Embedded pages should say "I should only be embedded in specific sites", where the specific site can be "same server as this code" or a list of servers.

Then the browsers check to see if your content is embedded someplace where it does not belong.

Wikipedia says that X-Frame-Options is older while Content-Security-Policy is the newer, and fully standardized version.   The newer one is preferred but it is acceptable to use both to cover all bases.

From a web design standpoint, you need to know what stuff is embedded where, so it helps to have a development environment that helps you keep track of this stuff.

Not sure how big a risk this is, and it is technically not your problem.    You can probably use the UTM login page templates to add the header, but User Portal was not modifiable in 9.5.   Has that changed in 9.6?   And  you need to worry about whether the back-end WAF application complies with the policy and continues to assert it.