X frame options weak
Quick winReplace the weak X-Frame-Options header value with DENY or SAMEORIGIN to prevent clickjacking attacks on your store.
What it is
The `X-Frame-Options` HTTP response header tells browsers whether your website is allowed to be loaded inside an `<iframe>`, `<frame>`, or `<object>` on another site. There are two safe values: `DENY` (no framing allowed anywhere) and `SAMEORIGIN` (only your own site can frame your pages). A third value, `ALLOW-FROM`, was once supported to whitelist a specific external domain — but it is now obsolete, ignored by most modern browsers, and therefore provides no real protection. When this header is missing, set to an unsupported value like `ALLOW-FROM`, or combined with `SAMEORIGIN` in a way that browsers parse inconsistently, your pages are effectively unprotected against framing by attackers.
Why it matters
Without a properly enforced `X-Frame-Options` header, attackers can silently embed your store's checkout, login, or account pages inside invisible iframes on malicious websites — a technique called clickjacking. A shopper thinks they're clicking a button on the attacker's page, but they're actually clicking your hidden iframe: entering payment details, changing account settings, or completing unwanted purchases. This is a real theft and fraud vector that can lead to chargebacks, customer complaints, regulatory scrutiny under PCI-DSS, and loss of consumer trust. Search engines like Google also consider security posture signals when evaluating site quality; a site known to be compromised through clickjacking can suffer ranking and reputation damage. Fixing this header takes under 30 minutes and closes the vulnerability entirely for all modern browsers.
How to fix it
- Audit your current X-Frame-Options header value by visiting a tool like securityheaders.com or using your browser's developer tools (Network tab → select any page response → look at the Response Headers section) to see the exact value being sent.
- Decide on the correct value: use DENY if no part of your site needs to be embedded in an iframe (recommended for most stores); use SAMEORIGIN if your own site legitimately embeds pages in iframes (e.g. a same-domain checkout widget). Remove any ALLOW-FROM directive entirely — it is obsolete and ignored by Chrome, Firefox, and Safari.
- Set the header at the server or platform level. The header should read exactly: X-Frame-Options: DENY — or — X-Frame-Options: SAMEORIGIN. Do not combine multiple values or add ALLOW-FROM alongside them.
- Supplement X-Frame-Options with a Content-Security-Policy (CSP) frame-ancestors directive (e.g. frame-ancestors 'none'; for DENY or frame-ancestors 'self'; for SAMEORIGIN), because CSP frame-ancestors is the modern replacement and is respected by all current browsers even where X-Frame-Options is not.
- Verify the fix: after deploying, reload your site and re-check the response headers. Confirm X-Frame-Options shows only DENY or SAMEORIGIN (not ALLOW-FROM, not both), and that the CSP header includes frame-ancestors.
- Re-run your security scan or use securityheaders.com to confirm the finding is resolved and no new header conflicts have been introduced.
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 automatically sends X-Frame-Options: DENY — you cannot override server-level response headers directly from the Shopify admin for the storefront.
- If your finding comes from an embedded app, custom storefront (Hydrogen/Headless), or a third-party integration (e.g. Contentstack), the header must be set in that app's server configuration or middleware, not in Shopify admin.
- For Hydrogen (custom storefronts): open your server.ts (or entry.server.tsx) file and add the header in the handleRequest function using: response.headers.set('X-Frame-Options', 'DENY') and response.headers.set('Content-Security-Policy', "frame-ancestors 'none';").
- For third-party embedded apps served from external servers: set the header in that server's configuration (Node.js, Vercel, Netlify, etc.) — see the Headless/Custom entry below.
- Verify by loading your storefront URL in a browser, opening DevTools → Network → select the document request → Response Headers.
How to fix x frame options weak on Shopify Plus
- Shopify Plus storefronts have the same built-in X-Frame-Options: DENY header as standard Shopify — no admin setting is needed or available for the core storefront.
- For custom checkout extensions or headless storefronts deployed on external infrastructure (e.g. Vercel, AWS), set the header at the hosting/server layer as described in the Headless/Custom entry.
- If using a Contentstack or similar CMS preview integration that sends a conflicting ALLOW-FROM header, contact that vendor and request they update their preview configuration to use Content-Security-Policy frame-ancestors instead.
- Verify headers via DevTools → Network tab on your storefront pages.
How to fix x frame options weak on WooCommerce
- Log in to your WordPress admin. Go to Plugins → Add New and search for 'Headers Security Advanced & HSTS WP' or 'HTTP Headers' (by BestWebSoft) — both allow setting custom HTTP headers without server access.
- Alternatively, if you have access to your web server config: for Apache, open your .htaccess file (in the WordPress root) and add: Header always set X-Frame-Options "DENY" and Header always set Content-Security-Policy "frame-ancestors 'none';"
- For Nginx servers, open your nginx.conf or the site's server block and add inside the server{} block: add_header X-Frame-Options "DENY" always; and add_header Content-Security-Policy "frame-ancestors 'none';" always;
- If using a managed WordPress host (WP Engine, Kinsta, SiteGround), check their dashboard for a 'Security Headers' or 'HTTP Headers' panel — most managed hosts provide a UI for this.
- Install a caching plugin like WP Rocket or W3 Total Cache only after setting headers to ensure cached responses also include the updated headers.
- Verify with DevTools → Network → Response Headers on your site's homepage and checkout page.
How to fix x frame options weak on WordPress.org
- Same as WooCommerce above — WordPress.org self-hosted sites use Apache or Nginx server config or a security/headers plugin.
- For Apache: add to your .htaccess file in the site root — Header always set X-Frame-Options "DENY"
- For Nginx: add to your server block — add_header X-Frame-Options "DENY" always;
- Recommended plugin: 'HTTP Headers' by BestWebSoft (Settings → HTTP Headers → Add Header → X-Frame-Options → DENY) or 'Secure Headers' plugin.
- After saving, purge any caching layer and verify headers via DevTools.
How to fix x frame options weak on BigCommerce
- BigCommerce's managed hosting sets X-Frame-Options: SAMEORIGIN by default on storefront pages — you cannot directly override HTTP response headers from the BigCommerce control panel for the core storefront.
- If the weak header originates from a custom headless frontend, a third-party app, or a middleware layer (e.g. a Contentstack preview URL), configure the header in that service's server settings.
- For headless BigCommerce storefronts (Next.js, Gatsby, etc.) deployed on Vercel or Netlify: add a vercel.json or netlify.toml headers block (see code snippets below).
- For app-level concerns, contact BigCommerce support (Support → Submit a Case) to confirm the expected header behavior and request guidance on overriding it at the CDN/edge layer.
- Verify storefront response headers using DevTools → Network on your live store URL.
How to fix x frame options weak on Adobe Commerce (Magento)
- SSH into your server or use your hosting control panel to access your Nginx or Apache config.
- For Nginx: edit /etc/nginx/nginx.conf or the Magento vhost config (commonly /etc/nginx/sites-available/magento.conf) and add inside the server{} block: add_header X-Frame-Options "DENY" always; and add_header Content-Security-Policy "frame-ancestors 'none';" always;
- For Apache: edit your .htaccess in the Magento root (pub/.htaccess for Magento 2) and add: Header always set X-Frame-Options "DENY"
- Alternatively in Magento 2 Admin: go to Stores → Configuration → General → Web → and look for the 'X-Frame-Options Header' field (available in some versions) — set it to SAMEORIGIN or DENY.
- If running Magento 2.4+: you can also set this in app/etc/env.php or via a custom module that injects the header through a response plugin (interceptor on Magento\Framework\App\Response\Http).
- After deployment, run: bin/magento cache:flush, then verify headers with DevTools or curl -I https://yourdomain.com.
How to fix x frame options weak on Magento Open Source
- Follow the same steps as Adobe Commerce (Magento) above — the server-level config and Magento 2 Admin path are identical for Magento Open Source.
- For Apache, add to pub/.htaccess: Header always set X-Frame-Options "DENY"
- For Nginx, add to the server{} block in your vhost config: add_header X-Frame-Options "DENY" always;
- Flush cache: bin/magento cache:flush, then verify with curl -I https://yourdomain.com | grep -i x-frame.
How to fix x frame options weak on Wix
- Wix manages all HTTP response headers at the infrastructure level — you cannot set custom response headers directly from the Wix dashboard for standard pages.
- If the weak header is coming from a Wix site: contact Wix Support (Help Center → Contact Us) to report the misconfigured X-Frame-Options header and request it be corrected to DENY or SAMEORIGIN.
- If you use Wix Velo (custom code): you can set headers in HTTP Functions (http-functions.js) for API endpoints you build, but not for the main page responses served by Wix's CDN.
- As a workaround for embedding prevention, use Wix's built-in 'iFrame blocking' settings if available in your plan, or ensure sensitive pages (Members area, checkout) are not embeddable by confirming with Wix support.
How to fix x frame options weak on Wix Studio
- Same infrastructure constraints as standard Wix — response headers for the core storefront are managed by Wix and cannot be overridden from the Studio editor.
- For custom backends built with Wix Studio's HTTP functions, you can set headers within those function responses in your http-functions.js file.
- Contact Wix Studio support for any header corrections needed on primary page responses.
How to fix x frame options weak on Squarespace
- Squarespace manages HTTP headers at the infrastructure level — there is no admin UI to set custom response headers.
- Squarespace already sends X-Frame-Options: SAMEORIGIN on most page responses. If a scan reports a weak value (e.g. ALLOW-FROM from an integrated third-party service), the issue is in that third-party service's configuration, not Squarespace itself.
- Contact Squarespace Support (Help → Contact Us) to report the specific header issue and request an update.
- If the offending header comes from a third-party embed (e.g. a CMS preview iframe), contact that vendor to update their response headers to use Content-Security-Policy frame-ancestors instead of ALLOW-FROM.
How to fix x frame options weak on Webflow
- Webflow does not provide a UI to set custom HTTP response headers for standard hosted sites.
- If your Webflow site is published to a custom domain and proxied through Cloudflare (common setup): log in to Cloudflare → your domain → Rules → Transform Rules → Modify Response Header → Add Rule → set Header Name: X-Frame-Options, Value: DENY, Action: Set.
- Also add a second rule for Content-Security-Policy with value: frame-ancestors 'none';
- If not using Cloudflare: contact Webflow support to report the issue, or export your site and host it on a server where you control headers (e.g. Netlify — see below).
- For Webflow exported sites on Netlify: add a netlify.toml file to the repo root with the headers block shown in the code snippets below.
How to fix x frame options weak on Headless / Custom (I build in code)
- For Node.js / Express: use the 'helmet' npm package — app.use(helmet.frameguard({ action: 'deny' })) — which sets X-Frame-Options: DENY and you can separately add a CSP header with frame-ancestors 'none'.
- For Next.js: add headers to next.config.js in the headers() async function (see code snippet below).
- For Vercel deployments: add a vercel.json file to your project root with a headers array entry for X-Frame-Options: DENY (see code snippet below).
- For Netlify deployments: add a netlify.toml file with a [[headers]] block, or add a _headers file to your publish directory (see code snippet below).
- For Apache: add to .htaccess — Header always set X-Frame-Options "DENY"
- For Nginx: add to server{} block — add_header X-Frame-Options "DENY" always;
- Always pair X-Frame-Options with Content-Security-Policy: frame-ancestors 'none'; for full modern browser coverage.
- Verify with: curl -I https://yourdomain.com | grep -i -E 'x-frame|content-security'
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.
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.
Does your site have this issue?
Run a free SEOLZ scan to find x frame options weak — and every other issue — across your whole site in minutes.
Scan my site freeFrequently asked questions
What is X frame options weak?
The `X-Frame-Options` HTTP response header tells browsers whether your website is allowed to be loaded inside an `<iframe>`, `<frame>`, or `<object>` on another site. There are two safe values: `DENY` (no framing allowed anywhere) and `SAMEORIGIN` (only your own site can frame your pages). A third value, `ALLOW-FROM`, was once supported to whitelist a specific external domain — but it is now obsolete, ignored by most modern browsers, and therefore provides no real protection. When this header is missing, set to an unsupported value like `ALLOW-FROM`, or combined with `SAMEORIGIN` in a way that browsers parse inconsistently, your pages are effectively unprotected against framing by attackers.
Why does x frame options weak matter?
Without a properly enforced `X-Frame-Options` header, attackers can silently embed your store's checkout, login, or account pages inside invisible iframes on malicious websites — a technique called clickjacking. A shopper thinks they're clicking a button on the attacker's page, but they're actually clicking your hidden iframe: entering payment details, changing account settings, or completing unwanted purchases. This is a real theft and fraud vector that can lead to chargebacks, customer complaints, regulatory scrutiny under PCI-DSS, and loss of consumer trust. Search engines like Google also consider security posture signals when evaluating site quality; a site known to be compromised through clickjacking can suffer ranking and reputation damage. Fixing this header takes under 30 minutes and closes the vulnerability entirely for all modern browsers.
How do I fix x frame options weak?
Replace the weak X-Frame-Options header value with DENY or SAMEORIGIN to prevent clickjacking attacks on your store.
Authoritative references
- OWASP Top Ten — OWASP
- OWASP Cheat Sheet Series — OWASP
- Secure Headers Project — OWASP
- Website security — MDN