FRAMING PROTECTION

Clickjacking Checker

Check if your page can be framed by other sites, which is the precondition for clickjacking, using X-Frame-Options and the frame-ancestors directive.

Run Framing protection

The domain (or a subdomain). The check stays within that name and its www counterpart, like the full assessment.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What clickjacking is

In a clickjacking attack, a malicious page loads your site inside an invisible or disguised frame and tricks a visitor into clicking something there: a button, a confirmation, a settings toggle. The visitor believes they are interacting with the attacker's page, but the click lands on yours, with the visitor's session. The defence is for your site to tell browsers which origins may embed it, so a hostile page cannot frame it in the first place.

Two headers do this. X-Frame-Options is the older one. The frame-ancestors directive of Content-Security-Policy is the modern one and takes precedence in browsers that support both.

How to read the result

The tool shows each header's value and what it means, and then the combined effect.

  • X-Frame-Options: DENY: no site, including yours, may frame the page.
  • X-Frame-Options: SAMEORIGIN: only pages from the same origin may frame it.
  • ALLOW-FROM: obsolete. Current browsers ignore it, so it provides no protection and needs replacing by frame-ancestors.
  • frame-ancestors: a list of allowed embedders, for example 'none', 'self' or specific origins. This directive is the flexible, current method.
  • Both present but disagreeing: for example DENY alongside a frame-ancestors allowing an origin. Browsers that support CSP follow frame-ancestors, so the more permissive value wins in practice.
  • Neither present: the page can be embedded anywhere; this is reported as a low-severity improvement.
  • Unrecognised value: the header is counted as present by the assessment, but browsers do not enforce it, so the tool notes that framing is effectively unrestricted.

Which pages need protection

Pages that perform actions or reveal data to a signed-in user matter most: logins, account settings, payment confirmation, admin screens, consent prompts. A static informational page that nothing sensitive depends on has little to lose from being framed. Some pages must be embeddable, such as widgets, video players or pages designed to appear in partner portals; for these, use frame-ancestors with an explicit list of the permitted origins rather than leaving framing open to everyone.

Framing and user experience

Blocking framing can have side effects that are easy to overlook. Single sign-on flows sometimes load a login page inside a frame, preview features in content-management systems embed your own pages, and help-desk or dashboard tools may show your site in a panel. Test those paths before enforcing DENY. The same header applies to every response that carries it, including error pages, so apply protection consistently rather than only on the home page.

Common problems

  • Header only on the main site: login or API subdomains behind another proxy send nothing.
  • Legitimate embedding broken after adding DENY, because a partner or internal tool frames the page.
  • ALLOW-FROM copied from old guides and silently ignored.
  • Header present on the landing page but missing on sensitive paths, which this tool cannot see.
  • CSP not including frame-ancestors when relying on a policy for other purposes.

How to fix framing safely

Prerequisites: a list of origins that legitimately embed your pages, including internal tools, and knowledge of where headers are set. Risk: a too-strict value breaks real embeds. Rollback: keep the old header configuration and revert if an embed fails.

  1. Search logs or ask partners to determine which origins frame your pages.
  2. If none, set Content-Security-Policy: frame-ancestors 'none' and X-Frame-Options: DENY. If same-origin only, use 'self' and SAMEORIGIN.
  3. If specific origins need access, list them in frame-ancestors and omit X-Frame-Options, which cannot express a list.
  4. Remove ALLOW-FROM entries.
  5. Re-run this checker, and test a real embed from an allowed and a disallowed page.

Limits

Only the landing page's headers are examined, and individual pages may differ. A policy set through a meta tag is not honoured for framing and is not seen. The tool does not attempt to frame your site or exploit anything. Framing protection does not prevent every UI-redress technique; it prevents cross-origin embedding of the page.

Frequently asked questions

Is X-Frame-Options still needed if I use frame-ancestors?

Browsers that support frame-ancestors use it. Keeping X-Frame-Options helps very old browsers and does no harm if the two agree.

Why is ALLOW-FROM flagged?

Current browsers ignore it, so a site relying on it is effectively unprotected.

Can I allow one partner and block everyone else?

Yes, with frame-ancestors listing that origin. X-Frame-Options cannot express this.

Does framing protection stop all clickjacking?

It stops cross-origin framing of the page. Other deceptive-interface techniques need other defences.

Will this break my own iframes?

Not with SAMEORIGIN or 'self', but a page that frames a different origin's content is controlled by that origin's headers.

Is a missing header an emergency?

No. It is a low-severity improvement, more urgent for pages with sensitive actions.

Scope of this tool

  • Only the domain's apex and www host are contacted over HTTPS (and port 80 where stated); redirects to any other host are reported, never followed.
  • Spectra identifies itself honestly and does not imitate a browser, so sites that block automated clients may not show their real headers.
  • A single request path (/) is examined from this scanner's network position; other pages, other nodes of a load-balanced site and other regions may differ.
  • If a header is sent more than once, only the first occurrence is examined.
  • Error and redirect responses are not judged: their headers are not representative of the site.

Written by DNS Tools editorial · Last updated 2026-10-09