[whatwg] Allowing Clickjacking Prevention using a Minimal Javascript API

Rob Ennals rje at google.com
Wed Aug 17 15:51:39 PDT 2011

Hi Guys,

I'd like to present a proposal for a minimal API that would allow
clickjacking prevention, while still allowing useful cross-domain
iframing such as share buttons etc.

(for context: http://en.wikipedia.org/wiki/Clickjacking)

To allow an iframe to detect clickjacking, the browser would provide
API functions to determine the following:
* The origins of all enclosing documents
* The size of the iframe viewport
* Whether any of the iframe content might be covered by something else
    - scrolled into view, and no overlapping rectangles with higher z-order
* It's absolute position in the window
* The complete computed style applied to the iframe (e.g. is it zoomed
or transparent)
* Receive an event whenever any of these change
* Any other information I've forgotten that might indicate clickjacking

The intention is that the browser would expose sufficient information
to allow the iframe to detect clickjacking if it happens.
Responsibility for detecting clickjacking is passed over to the iframe
javascript. The browser just gives the iframe the tools it needs to do
it's job.

A developer would not be expected to implement clickjacking detection
themselves. Instead they would import a standard library that does it.
Such a library could be included as a default part of libraries like
Closure and jQuery.

Several proposals for preventing clickjacking have been proposed
before, but, as yet, browsers do little to prevent clickjacking, other
than X-Frame-Options, which disallows cross-domain iframing

Michal Zelewski sent out an interesting proposal back a while back,
but that seems to have been rejected on the grounds that it was
complex to implement, and it wasn't clear that the proposed solution
would be the correct one in all use cases.

NoScript's ClearClick also does similar client-side checking.

The motivation behind the proposal above is:
* Make it be something that is minimal enough that browser vendors can
implement it relatively easy.
* Don't make any claims about it being complete. Instead allow library
vendors to explore the appropriate rules to use to disallow




More information about the whatwg mailing list