Pages can be embedded by other sites (clickjacking)

SeverityMedium

ScopeWhole site

EffortSmall

Verified bySecurity scan (weekly, or Re-scan)

Rule keysec_clickjacking

Short answer

Your home page sends neither X-Frame-Options: DENY or SAMEORIGIN nor a CSP frame-ancestors directive, so any website can embed it in an invisible iframe. An attacker can then place your real buttons (log in, buy, delete, approve) under their own decoy content so that a visitor's click lands on your page. One response header fixes it.

Why it matters

Clickjacking abuses the visitor's existing session on your site: if an editor is logged in, a hidden frame can make them change a setting, publish or approve something with a single click. Framing is also used to pass your pages off inside someone else's site. There is no ranking effect, and blocking framing does not affect Googlebot, which loads your pages directly rather than inside other sites.

How Glimana detects it

Glimana reads the response headers of your HTTPS home page. The check passes when X-Frame-Options is DENY or SAMEORIGIN, or when the Content-Security-Policy response header contains a frame-ancestors directive that does not include *. Otherwise it fails with medium severity. The obsolete ALLOW-FROM value also fails, and frame-ancestors inside a CSP meta tag does not count, because browsers ignore it there.

How to fix it

Watch out

If your pages are legitimately shown in frames elsewhere (your other domains, a partner portal, a page builder preview), DENY or SAMEORIGIN will break that. Use frame-ancestors 'self' https://partner.example in the CSP header instead; X-Frame-Options: ALLOW-FROM is ignored by current browsers. When both headers are present, browsers that support frame-ancestors follow it and ignore X-Frame-Options.

Find the finding in Glimana. Open Security; this check is in the Security headers group, with the evidence from the last scan under its title. The same problem is listed under Issues › Pages can be embedded by other sites (clickjacking).
Apply the fix on your platform.

WordPressCloudflareApache / Nginx

WordPress already sends X-Frame-Options: SAMEORIGIN on the login and admin screens, but not on public pages. Add it site-wide in .htaccess (Apache, mod_headers): Header always set X-Frame-Options "SAMEORIGIN". Many security plugins offer the same option; set it in one place only.

Rules › Settings › Managed Transforms: turn on Add security headers. It adds X-Frame-Options: SAMEORIGIN together with X-Content-Type-Options: nosniff and a few others, including Referrer-Policy: same-origin, which stops sending referrer data to other sites. For your own values, create a Response Header Transform Rule (Rules › Overview › Create rule) that sets X-Frame-Options, or a CSP header with frame-ancestors.

Nginx: add_header X-Frame-Options "SAMEORIGIN" always;
Apache: Header always set X-Frame-Options "SAMEORIGIN"
The modern alternative is frame-ancestors 'self' in your Content-Security-Policy header (a response header, not a meta tag).
Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.

How the fix is verified

Press Re-scan on the Security page (or wait for the weekly Sunday scan); the problem closes when the check passes.