X frame options weak

Quick win

Change the X-Frame-Options response header from its current weak or missing value to either DENY or SAMEORIGIN so your store cannot be embedded in a malicious iframe.

What it is

The X-Frame-Options HTTP header is a one-line instruction your web server sends to every visitor's browser telling it whether your store's pages are allowed to be loaded inside an iframe (a "page within a page") on another website. There are two safe values: DENY (no site, including your own, can frame your pages) and SAMEORIGIN (only pages on your own domain can frame them). A weak or absent value means any website on the internet can load your store inside an invisible or disguised iframe — a classic attack called clickjacking.

Why it matters

Clickjacking lets attackers overlay your real checkout or login page inside a transparent iframe on a fake site, tricking customers into clicking buttons they can't see — handing over payment details, credentials, or completing purchases they didn't intend. This is a direct revenue, fraud, and brand-trust risk. It also violates PCI-DSS requirements around protecting cardholder data environments and can expose you to legal liability if customers are defrauded through your site. Google's Safe Browsing program can flag sites involved in such abuse, which destroys organic search rankings overnight.

How to fix it

Decide which value you need: choose DENY if your store pages never need to appear in an iframe on any site (safest, recommended for most stores); choose SAMEORIGIN only if you embed your own pages in iframes on your own domain.
Locate where HTTP response headers are set for your store — this is typically your web server config (Nginx, Apache), a CDN/proxy layer (Cloudflare, Fastly), or your platform's built-in header settings.
Add or update the header: X-Frame-Options: DENY (or SAMEORIGIN). If both X-Frame-Options and a Content-Security-Policy frame-ancestors directive are present, modern browsers honour CSP; keep both for maximum compatibility.
Deploy the change and verify it by loading any page of your store in a browser, opening DevTools (F12) → Network tab → click the main document request → inspect Response Headers for 'x-frame-options: DENY' (or SAMEORIGIN).
Use a free header-checker tool (e.g. securityheaders.com) to confirm the header is present and correctly valued across your domain.
Test that your own legitimate iframe embeds (widgets, live chat, embedded maps) still work as expected; if something breaks, switch from DENY to SAMEORIGIN.

X-Frame-Options: DENY

Fix it on your platform

Pick your platform for the exact steps.

How to fix x frame options weak on Shopify

Shopify's core storefront already sends X-Frame-Options: DENY on most pages and you cannot alter server-level headers directly.
For any custom Hydrogen (headless) or Oxygen-deployed storefront: open your server entry file (e.g. server.ts), find where you create the response or use a middleware, and add: response.headers.set('X-Frame-Options', 'DENY');
For theme-level customisation you cannot set HTTP headers — if a scanner flags your Shopify store, confirm the header is already present using DevTools or securityheaders.com; if it is missing only on a specific embedded app or custom domain, contact that app's developer.
Shopify Plus merchants using a custom domain behind Cloudflare: add a Transform Rule in Cloudflare dashboard → Rules → Transform Rules → Modify Response Header → add X-Frame-Options = DENY.

Full Shopify guide →Official Shopify docs ↗

How to fix x frame options weak on WooCommerce

Install the free plugin 'HTTP Headers' (by David Gwyer) or 'Security Headers' from the WordPress plugin directory.
In WordPress admin go to Settings → HTTP Headers (or the plugin's menu), find X-Frame-Options, set the value to DENY, and save.
Alternatively, edit your theme's functions.php (or a site-specific plugin): add add_action('send_headers', function(){ header('X-Frame-Options: DENY'); });
Or add it directly in your .htaccess file (Apache): Header always set X-Frame-Options "DENY"
Or in Nginx server block: add_header X-Frame-Options "DENY" always; — place inside the server {} block and reload Nginx.
Verify with DevTools → Network → document response headers.

Full WooCommerce guide →Official WooCommerce docs ↗

How to fix x frame options weak on BigCommerce

BigCommerce SaaS storefronts set X-Frame-Options automatically; use DevTools to confirm it is present on your live store.
If your store sits behind a CDN such as Cloudflare, go to Cloudflare dashboard → your domain → Rules → Transform Rules → Modify Response Header → Create rule → Add header: Name = X-Frame-Options, Value = DENY. Set it to apply to all requests matching your hostname.
For BigCommerce headless (Next.js / React) storefronts deployed on Vercel: add to vercel.json: { "headers": [{ "source": "/(.*)", "headers": [{ "key": "X-Frame-Options", "value": "DENY" }] }] }
For headless storefronts on Netlify: add to netlify.toml: [[headers]] for = "/*" [headers.values] X-Frame-Options = "DENY"

Full BigCommerce guide →Official BigCommerce docs ↗

How to fix x frame options weak on Adobe Commerce (Magento)

In the Magento admin panel go to Stores → Configuration → General → Web → Default Pages — look for any built-in header setting (varies by version).
The most reliable method: open your Nginx vhost config for Magento (typically /etc/nginx/sites-available/your-store.conf) and inside the server {} block add: add_header X-Frame-Options "DENY" always; Reload Nginx: sudo nginx -s reload
For Apache: open your .htaccess or VirtualHost config and add: Header always set X-Frame-Options "DENY" Then restart Apache.
Alternatively install the Magento 2 module 'magento2-security-headers' via Composer: composer require your-vendor/security-headers, then run bin/magento setup:upgrade and configure in admin.
Verify by loading your storefront and inspecting response headers in DevTools.

Full Adobe Commerce (Magento) guide →Official Adobe Commerce (Magento) docs ↗

How to fix x frame options weak on Wix

Wix does not provide direct HTTP response header control for standard sites.
Wix sets its own X-Frame-Options policy on the platform; verify what is currently sent using DevTools or securityheaders.com on your live Wix domain.
If the header is missing or weak, submit a support request to Wix to ask about their security header policy — this is an infrastructure-level setting for standard Wix.
Wix Studio / Velo advanced sites: you can add custom HTTP headers via Wix's HTTP functions (wix-http-functions) for specific API routes, but full page response headers remain platform-controlled.
For maximum control, consider routing traffic through Cloudflare (add your Wix site's DNS to Cloudflare, proxied) and use Cloudflare Transform Rules to inject X-Frame-Options: DENY on all responses.

Full Wix guide →Official Wix docs ↗

How to fix x frame options weak on Squarespace

Squarespace does not allow direct HTTP response header customisation for standard plans — headers are controlled at the platform infrastructure level.
Verify the current header value using DevTools (F12 → Network → document → Response Headers) or securityheaders.com.
If X-Frame-Options is missing or weak, route your custom domain through Cloudflare (set DNS to Cloudflare proxied), then in Cloudflare dashboard → Rules → Transform Rules → Modify Response Header → add X-Frame-Options = DENY for all requests.
Contact Squarespace support to report the missing header and request they apply it platform-wide.

Full Squarespace guide →Official Squarespace docs ↗

How to fix x frame options weak on Webflow

Webflow hosting does not currently expose a UI to set custom HTTP response headers for page responses.
Route your Webflow site through Cloudflare: point your custom domain's DNS to Cloudflare (proxied), then in Cloudflare dashboard → Rules → Transform Rules → Modify Response Header → Create rule → Add header: X-Frame-Options = DENY, apply to hostname matching your domain.
If exporting Webflow code and self-hosting on Nginx: add add_header X-Frame-Options "DENY" always; inside your server {} block.
If self-hosting on Apache: add Header always set X-Frame-Options "DENY" to your .htaccess or VirtualHost config.
Verify the header is present after applying the rule using DevTools or securityheaders.com.

Full Webflow guide →Official Webflow docs ↗

How to fix x frame options weak on WordPress.org

Install the 'HTTP Headers' plugin (by David Gwyer) or 'Headers Security Advanced & HSTS WP' from the WordPress plugin repository.
In WordPress admin, navigate to the plugin's settings page, locate X-Frame-Options, select DENY (or SAMEORIGIN), and save.
Without a plugin, add to your active theme's functions.php or a must-use plugin: add_action('send_headers', function(){ header('X-Frame-Options: DENY'); });
Apache server: open wp-content or root .htaccess and add inside the <IfModule mod_headers.c> block: Header always set X-Frame-Options "DENY"
Nginx server: add add_header X-Frame-Options "DENY" always; inside the server {} block in your site config, then sudo nginx -s reload.
Confirm with DevTools → Network → select the HTML document → Response Headers.

Full WordPress.org guide →Official WordPress.org docs ↗

How to fix x frame options weak on Next.js

Open next.config.js and add a headers() export: async headers() { return [{ source: '/(.*)', headers: [{ key: 'X-Frame-Options', value: 'DENY' }] }]; }
Restart your Next.js server (or redeploy to Vercel/your host) and verify with DevTools.

Full Next.js guide →Official Next.js docs ↗

How to fix x frame options weak on Nuxt.js

Install the nuxt-security module: npm install nuxt-security
In nuxt.config.ts add: security: { headers: { xFrameOptions: 'DENY' } }
Rebuild and redeploy; verify the header in DevTools.

Full Nuxt.js guide →Official Nuxt.js docs ↗

Does your site have this issue?

Run a free SEOLZ audit to find x frame options weak — and every other issue — across your whole site in minutes.

Scan my site free

Frequently asked questions

What is X frame options weak?

Why does x frame options weak matter?

How do I fix x frame options weak?