Security
Your pages cannot be framed by another site
security.missing-frame-options
Why this matters
Without this, someone can load your site inside an invisible frame on their own page and trick visitors into clicking your buttons while thinking they are clicking something else. It is most often used against login and payment forms.
Who fixes it
You can, usually
Roughly how long
Minutes
Care needed
Low risk to change
How to fix it
Send `X-Frame-Options: SAMEORIGIN`, or the modern equivalent `Content-Security-Policy: frame-ancestors 'self'`. Only relax it if you genuinely need a partner site to embed you.
On your platform
WordPress
Set by your host, not by WordPress. Add `X-Frame-Options: SAMEORIGIN` in Cloudflare if you use it, or in `.htaccess` on Apache hosting via a `Header always set` line. On managed WordPress hosting, ask support — most will add it and several set it already. A security plugin will also do it if you have no server access at all.
Shopify
Shopify controls storefront response headers and merchants cannot add them, so this is not something you can change. Shopify applies its own framing protection to checkout, which is where it matters most for a shop.
Drupal
Either in the web server configuration, or with the Security Kit (`seckit`) module, which has a setting for exactly this and needs no server access.
Joomla
Enable the System – HTTP Headers plugin (Joomla 4 and 5) and switch on X-Frame-Options. It defaults to SAMEORIGIN, which is what you want, and it needs no server access.
How we score it
Failing this check takes up to 8 points off your security score. It is a fact about your site rather than a measurement, so it reads the same on every scan until you change something.
Does your site pass this one?
This check runs on every scan, along with the other 106. Free, no account, and you see the evidence for each result.
Check my siteOther security checks
- A content security policy is in placeA content security policy tells the browser which scripts it may run. Without one, anything that manages to get injected into a page — through a compromised plugin, a hijacked advert, or a comment field — runs with the same trust as your own code.
- Browsers are told to stay on HTTPSYour site works over HTTPS, but it never tells browsers to remember that. The very first visit of the day can still be sent over an insecure connection before the redirect happens, which is the window an attacker on shared Wi-Fi needs.
- Camera, microphone and location access are restrictedAnything embedded in your pages — an advert, a chat widget, a map — can ask the visitor for access to their camera, microphone or location, and the request appears to come from you.
- Cookies are only sent over an encrypted connectionA cookie without the Secure flag is sent over a plain, unencrypted connection as readily as over an encrypted one. Anyone sharing a network with the visitor — a café, a hotel, an office guest network — can read it, and a single request to the http version of the site is enough to expose it, even when every page normally redirects to https. The flag costs nothing and there is no reason for a cookie on a secure site to be missing it.
- File types cannot be second-guessedWithout this header a browser may ignore what your server says a file is and guess instead. An uploaded image that is secretly a script can then be run as one.
- Folders are not browsableYour server is showing a file listing instead of a page. Anyone can read it and see exactly what is in that folder — backups, spreadsheets, database dumps, anything left there and forgotten.