Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both. Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker. [OWASP-CJ]
Summary: Content Security Policy has more fine-grained control and better rollout-strategy. But CSP Level 2, which includes the frame-ancestors directive, is not fully adopted yet. So use X-Frame-Options for now.
The best way to protect against Clickjacking is to have the browser prevent iFraming across domains. Specifically, in the edX case, we want to prevent non-edX web pages from iFraming edX content. We do this by providing iFraming rules in our web responses that are then enforced by web browsers. There are 2 HTTP response headers that govern this: (1) X-Frame-Options and (2) frame-ancestors directive in Content-Security-Policy.
Summary: Test with CSP, then deploy with X-Frame-Options.
Content Security Policy (CSP) has a great roll-out model as it allows us to first deploy new policies with reporting only capabilities (and no prevention). This allows us to find if there are any legitimate exceptions to the policy that should be excluded before actually enabling and enforcing the policy in production.
Once we have tested our policy on production using CSP, we can then implement the policy using the X-Frame-Options header response, per OWASP recommendation.
Summary: There is django Native support for using the X-Frame-Options header, but not for CSP yet.
Middleware: django has a built-in middleware (XFrameOptionsMiddleware) for automatically adding the X-Frame-Options header to all HTTP responses from the web server.
Default setting: The X-Frame-Options header value is set in the X_FRAME_OPTIONS django setting and can have the following values:
View Decorators: The header value can be overridden using the following xframe-options decorators:
CSP: See Implementation section of Content Security Policy.