Suppose my site does not have the concept of a user account... Then is a clickjacking attack still applicable to my site?

Even though there are no accounts, if there is a concept of user sessions, then Clickjacking could possibly apply. It all depends on what is being stored at session level.

The best way to think of this is that if your site remembers state at session level, and you are not setting X-Frame-Options to prevent framing, then an attacker could possibly trick a user into submitting this state information in order to execute an action.

An example:

1. User adds a "widget" to their basket on your site.

2. User goes to checkout and enters their personal information and card details.

3. This information is stored server side in the user session, identified via a random token which is stored in a cookie.

4. The user gets redirected to a confirmation page so they can check their details before sending the order: A GET request to example.com/confirm.php shows their order and they can click a submit button to to complete their order which submits an empty form resulting in a POST request to complete.php.

Now an attacker could frame the confirm.php page and display another button over the top so when the user clicks the button they submit their order to your site. Maybe this could be combined with a CSRF vulnerability for adding items to a user's basket, and could be executed at a point where it is known that session is populated (maybe the attacker has gained control of one of the advertiser's sites that are displayed after the user's first checkout and this vulnerability allows them to do it again with an item of the attacker's choosing).

So yes, your site could be vulnerable and it is down to the specific implementation details and the business model of your site to see whether it poses a real threat or not.

Suppose my site does not have the concept of a user account... Then is a clickjacking attack still applicable to my site?

Even though there are no accounts, if there is a concept of user sessions, then Clickjacking could possibly apply. It all depends on what is being stored at session level.

The best way to think of this is that if your site remembers state at session level, and you are not setting X-Frame-Options to prevent framing, then an attacker could possibly trick a user into submitting this state information in order to execute an action.

The other requirement would be a clickable item somewhere on your site, usually a button, that doesn't require any input on the page except for the click.

Clickjacking is sort of a "way to circumvent" CSRF protection on pages where no user input is required to submit them.

An example:

1. User adds a "widget" to their basket on your site.
2. User goes to checkout and enters their personal information and card details.
3. This information is stored server side in the user session, identified via a random token which is stored in a cookie.
4. The user gets redirected to a confirmation page so they can check their details before sending the order: A GET request to example.com/confirm.php shows their order and they can click a submit button to to complete their order which submits an empty form (except for a CSRF token) resulting in a POST request to complete.php.

Now an attacker could frame the confirm.php page and display another button over the top so when the user clicks the button they submit their order to your site. Maybe this could be combined with a CSRF vulnerability elsewhere for adding items to a user's basket, and could be executed at a point where it is known that session is populated (maybe the attacker has gained control of one of the advertiser's sites that are displayed after the user's first checkout and this vulnerability allows them to do it again with an item of the attacker's choosing).

So yes, your site could be vulnerable and it is down to the specific implementation details and the business model of your site to see whether it poses a real threat or not.