List News Background articles Commentaries Development/Java IT Security Computer Guides & Tips

Secure Programming of Web Applications: Clickjacking

Added at 12/15/2020 by Frank Hissen

We can read about numerous successful attacks on well-known web applications on a weekly basis. Reason enough to study the background of "Web Application Security" of custom-made / self-developed applications - no matter if these are used only internally or with public access.

This is an excerpt from the book "Secure Programming of Web Applications: Web Application Security for Software Developers and Project Managers"


Using the HTML element "iframe" arbitrary web sites or URLs can be integrated into the own web site. This is the standard behavior of web browsers. The "same-origin policy" indeed prevents by default that, e.g., a JavaScript of the embedding site accesses the content of a third-party page. However, the web page in the iframe works exactly like it would be opened in an own browser window or tab. That means all cookies and hence open sessions are active - simply within the iframe but on a different web site.

This can be exploited by malicious pages to mislead and trick regular users to execute certain actions or transactions undetected.

This concerns especially web forms, functions and JavaScript triggers of web applications that perform data modification and transactions. Simple data queries are not affected.

Eventually, a successful attack in this case works based on "UI tricks". However, there are no limits for the attacker's creativity to do so. For instance, the content of an iframe can be positioned at a certain position, the iframe can be created without scrollbars with a certain size. This could result in just a visible button of the victim's page - embedded in the external / attacker's site.
Another possibility is using transparent UI elements to create unsuspicious graphics to click on but actually perform unwanted clicks on the victim's page.

Secure Programming:

There basically exist two solutions. It has to be noticed that in certain application scenarios it is indeed desired that a web application can be used within an iframe. However, in such cases the whitelisting philosophy has to be implemented as far as possible. That means that all domains which are allowed to use the web application within an iframe have to be explicitly defined.


The HTTP header


is a browser directive which is supported by all modern browsers and restricts the default behavior - namely allowing embedding the own page everywhere. It supports the value "DENY" which forbids the embedding into iframes completely and the value "SAMEORIGIN" which allows the embedding solely into the own page / domain / URL.

"SAMEORIGIN" can be used, e.g., if a login form is made available under a certain URL and included in several sub areas of a web site using iframes. Correspondingly, there might be similar individual application scenarios.


A JavaScript-based solution which allows for more flexibility. However, it requires JavaScript to be enabled on the client-side. In this case, the following generally available JavaScript variable is used:


With this, arbitrary verification functions can be built to check the URL(s) of the embedding site (including the iframe) for validity. If this way an unauthorized embedding is detected, multiple reactions are possible. For instance, a simple error page could be displayed instead of the intended content or the top location could be changed so that the own web application will be display - maybe with a warning included. At all events, the actual functionality will be limited accordingly.


Clickjacking, Secure Programming, Web Applications, Web Application Security, OWASP, Software Development, IT Security, Awareness

Categories: IT Security Background articles Development/Java


Post your comment


If you like this page, it would be a great thing if you share it with others:

Mail Facebook Twitter Pinterest LinkedIn
reddit Digg StumbleUpon XING
WhatsApp Telegram