The clickjacking attack has been around for quite a while. A vulnerable application allows a malicious actor to load your web page in an iframe while overlaying it with transparent fields, buttons, and links that they control. This opens the door for creative ways to take advantage of this vulnerability.

For example, have you ever attempted to watch a video only to find out that when you click the play button it just loads a pop-up ad or goes to another web page? That’s an example of a clickjacking attack. Most likely the malicious actor is making money by having you click on this hidden advertisement link. This, of course, is costing money to the company that is inadvertently being advertised in this way. Although this may not seem like a threat to your personal online safety, using this same method a malicious actor can steal your account credentials. Actual username and password fields from a website you know and trust can be overlaid with opaque fields and a hidden button. So when you enter your credentials and hit submit, you actually just end up sending them to the malicious actor.

Fortunately, the w3c and the browser manufacturers have gone to great lengths to give you the tools to protect your customers. They created Content Security Policy(CSP) that you can implement in your web applications. Simply put, CSP is a browser enforced whitelist containing a list of domains your applications is allowed to interact with. To learn more about CSP please check out our recent blog post on the Top 3 Reasons to Get Started with Content Security Policy. To protect your application from clickjacking you would add all the URIs that are allowed to frame your application using the frame-ancestors directive.

Here is an example of what would be added to your HTTP response header:

Content-Security-Policy: frame-ancestors www.example.com

This would allow only www.example.com to frame your application. All other domains would fail to load in an iframe essentially preventing the possibility of a clickjacking attack. Additionally, you also have the option to only allow your own domain to frame itself or to disallow any URI from framing you all together. Together as the community of web content creators we can make the web a safer place and maintain the trust the users have placed in us to protect them. After all, our users are our guests and we should treat them accordingly.

Source(s): https://w3c.github.io/webappsec-csp/