SEOLZ

X content type options weak

Quick win

Set the X-Content-Type-Options response header to exactly `nosniff` (once, not duplicated) on every page and asset your store serves.

What it is

The `X-Content-Type-Options` HTTP response header is a one-line security instruction your web server sends to every visitor's browser. When set to `nosniff`, it tells the browser to trust the declared file type (e.g. "this is CSS" or "this is an image") and never try to guess or override it. A misconfigured header — such as sending the value twice (`nosniff, nosniff`), sending an empty value, or omitting it entirely — means the browser may ignore the instruction. This is classified as a Security Misconfiguration under OWASP A05:2021.

Why it matters

Without a valid `nosniff` directive, a browser may "MIME-sniff" a response — meaning it inspects the actual content of a file to decide what type it really is, overriding what your server declared. Attackers can exploit this to disguise a malicious script as an innocent image or text file; if a browser sniffs it and runs it as JavaScript, your customers can be exposed to cross-site scripting (XSS) attacks that steal payment data, session tokens, or account credentials. Beyond the direct security risk, this misconfiguration is flagged by security scanners and PCI-DSS auditors, and a duplicate or malformed header value (like `nosniff, nosniff`) signals misconfigured infrastructure that may undermine trust with both auditors and customers.

How to fix it

  1. Audit your current headers by loading your store URL in a browser and inspecting the Network tab (DevTools → Network → select any request → Headers) or using a tool like securityheaders.com — look for the `X-Content-Type-Options` header and confirm it appears exactly once with the value `nosniff`.
  2. Identify where the header is being set today: it may be set in your platform's admin/app, a CDN layer (Cloudflare, Fastly, etc.), a hosting server config file (.htaccess, nginx.conf), or a combination — duplicate values (`nosniff, nosniff`) are almost always caused by two layers each setting the header independently.
  3. Choose a single authoritative place to set the header and remove or disable it everywhere else to prevent duplication.
  4. Set the header value to exactly `nosniff` (lowercase, no extra spaces, no repetition): `X-Content-Type-Options: nosniff`
  5. Deploy the change, then re-verify with DevTools or securityheaders.com that the header appears exactly once with the correct value.
  6. If you use a CDN (Cloudflare, Fastly, etc.), check its 'Transform Rules' or 'Headers' settings as a separate layer that might be adding a second copy of the header.
X-Content-Type-Options: nosniff

Fix it on your platform

Pick your platform for the exact steps.

How to fix x content type options weak on Shopify
  1. Shopify's core storefront automatically sends `X-Content-Type-Options: nosniff` — if your scanner shows a duplicate or malformed value, the extra copy is almost certainly coming from a third-party app or a Cloudflare/CDN layer you've added.
  2. Check installed apps: Shopify Admin → Apps — look for any 'security headers' or 'HTTP headers' app and review its settings. Disable or remove any app that is independently setting this header.
  3. If you use Cloudflare in front of Shopify: Cloudflare Dashboard → your domain → Rules → Transform Rules → Modify Response Headers — delete any rule that sets `X-Content-Type-Options`, since Shopify already handles it.
  4. Verify the fix: open Chrome DevTools on your storefront, go to Network → select any page request → Headers, and confirm `X-Content-Type-Options: nosniff` appears exactly once.
Full Shopify guide →Official Shopify docs ↗
How to fix x content type options weak on Shopify Plus
  1. Same as Shopify above. Shopify Plus merchants should additionally check any custom Cloudflare Enterprise rules or edge middleware configured by their agency.
  2. Shopify Admin → Apps — audit all installed apps for header-manipulation behaviour.
  3. Cloudflare Dashboard → Rules → Transform Rules → Modify Response Headers — ensure no duplicate rule exists for `X-Content-Type-Options`.
  4. Use a staging/development store to verify headers before pushing changes to production.
Full Shopify Plus guide →Official Shopify Plus docs ↗
How to fix x content type options weak on WooCommerce
  1. Install the free 'HTTP Headers' plugin (author: John Henckel) or 'Headers Security Advanced & CORS' from the WordPress plugin directory.
  2. WordPress Admin → Settings → HTTP Headers (or the plugin's settings page) — find the `X-Content-Type-Options` field and set it to `nosniff`. Save.
  3. If you are also setting the header via your server (see below), disable it in one location to prevent duplication.
  4. Alternatively, edit your `.htaccess` file (Apache) in the WordPress root directory and add: `<IfModule mod_headers.c>` / `Header set X-Content-Type-Options "nosniff"` / `</IfModule>` — but only if you are NOT setting it via a plugin.
  5. For Nginx hosting, ask your host to add `add_header X-Content-Type-Options "nosniff" always;` to the server block in the nginx config, and remove any plugin that also sets it.
  6. Verify: use a browser's DevTools Network tab or securityheaders.com to confirm exactly one `nosniff` value.
Full WooCommerce guide →Official WooCommerce docs ↗
How to fix x content type options weak on WordPress.org
  1. Install the 'HTTP Headers' plugin or 'Solid Security' (formerly iThemes Security) from WordPress Admin → Plugins → Add New.
  2. Solid Security path: WordPress Admin → Security → Settings → Security Check → or search 'Security Headers' within the plugin — enable `X-Content-Type-Options: nosniff`.
  3. If your host (e.g. WP Engine, Kinsta, SiteGround) already injects this header at the server level, do NOT also add it via plugin — check your host's dashboard or contact support to confirm.
  4. Verify with DevTools or securityheaders.com.
Full WordPress.org guide →Official WordPress.org docs ↗
How to fix x content type options weak on BigCommerce
  1. BigCommerce's platform injects `X-Content-Type-Options: nosniff` by default on storefront responses.
  2. If your scanner reports a duplicate, the extra copy is likely coming from Cloudflare or another CDN/proxy sitting in front of your store.
  3. Log in to your Cloudflare (or other CDN) dashboard → Rules / Transform Rules → Modify Response Headers — remove any rule that adds `X-Content-Type-Options`, since BigCommerce already sets it.
  4. If you use a custom nginx or Apache reverse proxy, remove the header directive from that config.
  5. Verify with DevTools or securityheaders.com after clearing any CDN cache.
Full BigCommerce guide →Official BigCommerce docs ↗
How to fix x content type options weak on Wix
  1. Wix automatically adds security headers including `X-Content-Type-Options: nosniff` to all Wix-hosted sites — you cannot and do not need to set this manually in the Wix editor.
  2. If your scanner flags a duplicate, the issue is an upstream proxy or Cloudflare integration added to your domain.
  3. Remove any Cloudflare or third-party header-injection rule that duplicates `X-Content-Type-Options`.
  4. Contact Wix Support if you believe the platform itself is sending a malformed header.
Full Wix guide →Official Wix docs ↗
How to fix x content type options weak on Squarespace
  1. Squarespace automatically sets `X-Content-Type-Options: nosniff` on all hosted stores — no manual configuration is available or needed within the Squarespace UI.
  2. If a duplicate header is detected, audit any Cloudflare or CDN layer connected to your custom domain: Cloudflare Dashboard → Rules → Transform Rules → Modify Response Headers — remove any rule setting this header.
  3. Contact Squarespace Support if the platform itself is emitting a malformed or repeated value.
Full Squarespace guide →Official Squarespace docs ↗
How to fix x content type options weak on Webflow
  1. Webflow automatically sends `X-Content-Type-Options: nosniff` on all hosted projects.
  2. If a duplicate is found, check whether you have Cloudflare or another reverse proxy on your custom domain: Cloudflare Dashboard → Rules → Transform Rules → Modify Response Headers — delete any rule that also sets `X-Content-Type-Options`.
  3. For Webflow sites exported and self-hosted, add the header in your own server config (Apache `.htaccess` or Nginx server block) and ensure only one source sets it.
Full Webflow guide →Official Webflow docs ↗
How to fix x content type options weak on Adobe Commerce (Magento)
  1. SSH into your server and open your Nginx virtual host config (typically at `/etc/nginx/sites-available/your-store.conf` or inside `/etc/nginx/conf.d/`) or your Apache `.htaccess` / virtual host config.
  2. For Nginx, add inside the `server {}` block: `add_header X-Content-Type-Options "nosniff" always;` — remove any duplicate `add_header X-Content-Type-Options` lines in the same or parent blocks.
  3. For Apache, in `.htaccess` or VirtualHost config add: `<IfModule mod_headers.c>` / `Header set X-Content-Type-Options "nosniff"` / `</IfModule>` — remove any duplicate directives.
  4. Alternatively, configure it in Magento's `pub/.htaccess` or via a custom plugin/module that sets response headers.
  5. Reload/restart the web server (`sudo nginx -t && sudo systemctl reload nginx` or `sudo systemctl reload apache2`).
  6. Verify with DevTools or securityheaders.com.
Full Adobe Commerce (Magento) guide →Official Adobe Commerce (Magento) docs ↗
How to fix x content type options weak on Magento Open Source
  1. Follow the same Nginx/Apache steps as Adobe Commerce above.
  2. Check for any third-party Magento extension labelled 'Security Headers' in your Admin → System → Extensions — if one exists, disable the server-level directive and manage it only via the extension, or vice versa, to avoid duplication.
  3. Reload the web server and verify.
Full Magento Open Source guide →Official Magento Open Source docs ↗
How to fix x content type options weak on PrestaShop
  1. Edit your Apache `.htaccess` file in the PrestaShop root, or your Nginx server block config.
  2. Apache: add `Header always set X-Content-Type-Options "nosniff"` inside a `<IfModule mod_headers.c>` block.
  3. Nginx: add `add_header X-Content-Type-Options "nosniff" always;` in the server block.
  4. Remove any duplicate directives or conflicting module settings.
  5. Reload the web server and verify with DevTools.
Full PrestaShop guide →Official PrestaShop docs ↗

Does your site have this issue?

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

Scan my site free

Frequently asked questions

What is X content type options weak?

The `X-Content-Type-Options` HTTP response header is a one-line security instruction your web server sends to every visitor's browser. When set to `nosniff`, it tells the browser to trust the declared file type (e.g. "this is CSS" or "this is an image") and never try to guess or override it. A misconfigured header — such as sending the value twice (`nosniff, nosniff`), sending an empty value, or omitting it entirely — means the browser may ignore the instruction. This is classified as a Security Misconfiguration under OWASP A05:2021.

Why does x content type options weak matter?

Without a valid `nosniff` directive, a browser may "MIME-sniff" a response — meaning it inspects the actual content of a file to decide what type it really is, overriding what your server declared. Attackers can exploit this to disguise a malicious script as an innocent image or text file; if a browser sniffs it and runs it as JavaScript, your customers can be exposed to cross-site scripting (XSS) attacks that steal payment data, session tokens, or account credentials. Beyond the direct security risk, this misconfiguration is flagged by security scanners and PCI-DSS auditors, and a duplicate or malformed header value (like `nosniff, nosniff`) signals misconfigured infrastructure that may undermine trust with both auditors and customers.

How do I fix x content type options weak?

Set the X-Content-Type-Options response header to exactly `nosniff` (once, not duplicated) on every page and asset your store serves.

Authoritative references

Related Security (OWASP) issues