What is clickjacking, in plain terms?

An attacker loads your site into an invisible iframe on their own page, then layers convincing-looking buttons or content on top of it using CSS. A visitor thinks they're clicking the attacker's page, but the click actually lands on your site underneath, in the context of whatever session the visitor is already logged into.

Should I use DENY or SAMEORIGIN for X-Frame-Options?

SAMEORIGIN is right for almost every site. It stops any other domain framing your pages while still letting your own site frame itself, which some admin tools and preview features rely on. DENY is only worth using if nothing on the site should ever be loaded in a frame, including by itself.

Is ALLOW-FROM a safe value to use?

No. Every major browser dropped support for ALLOW-FROM years ago, so a header set to that value provides no protection at all, even though it looks like it should. Use SAMEORIGIN, or move the equivalent control into a Content-Security-Policy's frame-ancestors directive.

X-Frame-Options | mySites.guru

How common is this?

50.3% of the Joomla sites we have this data for fail this check. Platform: Joomla.

Measured across the sites we audit, on each site's most recent snapshot.

What this check and mySites.guru tool looks at on your site

mySites.guru requests a page from your Joomla extension site and inspects the raw HTTP response headers for X-Frame-Options, checking both that it’s present and that the value it carries is one browsers actually still honour. We check a page your server answers directly, such as a 404, rather than only the homepage, because headers added through a Joomla extension often only fire when PHP handles the request. Checking your website’s security headers with mySites.guru covers this check alongside the other three.

A click that isn’t going where it looks

Clickjacking is a deceptively simple attack. An attacker builds a page of their own, loads your site into an invisible <iframe>, and positions it using ordinary CSS so it sits directly underneath something that looks like a harmless button or link on their page. A visitor sees the attacker’s overlay, believes they’re clicking that, and clicks it. What actually receives the click is your site, hidden underneath, in a frame the visitor never knew was there.

The part that makes this dangerous rather than just annoying is that the browser executes that click in the context of whatever session the visitor already has open. If they’re logged into your Joomla extension admin area in another tab, an attacker can potentially frame an admin action, an account change, a form submission, and trick the visitor into triggering it without ever realising they interacted with your site at all. X-Frame-Options exists specifically to stop this, by telling the browser upfront whether your pages are allowed to be framed by anyone else.

The reason this still matters even on an ordinary brochure site, not just a bank or a webmail provider, is that the technique doesn’t need a dramatic target to be worth an attacker’s time. A single “delete my account” button, a newsletter unsubscribe link that also happens to trigger something else, or a contact form that’s really a password-reset confirmation dressed up differently, all become usable once an attacker can frame the page and layer their own content on top. The header is cheap to set and closes off the entire technique in one move, which is why it’s worth setting on every site regardless of how sensitive its content looks.

The value to set, and the one to avoid

For the great majority of sites, the correct value is:

X-Frame-Options: SAMEORIGIN

This blocks any other domain from framing your pages while still allowing your own site to frame its own pages, which some CMS admin previews and iframe-based tools depend on. DENY is stricter still and appropriate if literally nothing on the site should ever appear in a frame, including your own. Avoid ALLOW-FROM: it lets you name specific domains permitted to frame your site, but no current browser implements it any more, so a header set to that value is providing no real protection while looking like it is.

X-Frame-Options is being superseded, but still worth setting

Modern browsers honour the frame-ancestors directive inside a Content-Security-Policy header in preference to X-Frame-Options, and it offers finer control than a single header value allows. Set both where you can: frame-ancestors for browsers that support it, X-Frame-Options as a fallback for the ones that don’t. The same pattern applies elsewhere in this space, where Feature-Policy has been replaced by the newer Permissions-Policy header.

How to fix it

Set the header at server level so it applies to every response, not only the ones a Joomla extension can reach. In an .htaccess file, applied against https://yoursite.com/administrator and your front end:

Header always set X-Frame-Options "SAMEORIGIN"

On nginx, inside your server block:

add_header X-Frame-Options "SAMEORIGIN" always;

Decide whether anything on the site legitimately needs to frame itself, such as a preview panel or an embedded admin widget. If nothing does, use DENY instead of SAMEORIGIN.
Add the header at server or virtual host level rather than through a plugin, so it covers static assets and error pages, not only PHP-rendered ones.
If you’re setting a Content-Security-Policy too, add a matching frame-ancestors directive there as well, since it’s the value modern browsers will actually prefer.
Test by trying to frame your own site from an unrelated domain. A quick way to check is to save a small HTML file with <iframe src="https://yoursite.com"></iframe> and open it directly in a browser, from a different origin than your own site. It should refuse to load, and the browser console will usually name the header that blocked it.
Check anything that legitimately embeds your content elsewhere, such as an approved partner site, still works, since SAMEORIGIN will correctly block it too unless you’ve built that case into a frame-ancestors allow-list instead.

What mySites.guru does about it

Whether your site should ever be framed, and by whom, is a decision only you can make safely, so we don’t apply this automatically. mySites.guru checks for X-Frame-Options on every snapshot, twice a day, and shows you the exact value your site is currently sending, alongside the other response headers we check: Content-Security-Policy, Strict-Transport-Security and X-Content-Type-Options.

X-Frame-Options