If a security scan says your site is missing x-content-type-options wordpress, use this setting:
X-Content-Type-Options: nosniffThis response header is a short instruction sent with a web response. It tells browsers to respect the file type declared by the server instead of guessing. Add it where your site’s responses are served. Then check the public result. If you only have WordPress access, a plugin or WordPress code can help, but it may not cover every file.
TL;DR
Add X-Content-Type-Options: nosniff, then verify the public response with your browser’s network panel or a header check.
It reduces one content-type risk, but you should also keep WordPress updated and use a reputable security plugin for broader WordPress security.
What the header does
The Content-Type header labels a response as HTML, CSS, JavaScript, an image, or another file type. A browser can sometimes guess the type by examining the file contents. This is called MIME-type sniffing, which means inferring a file type when the server’s label is missing or unsuitable.
X-Content-Type-Options: nosniff tells the browser not to make that guess. For a script, the browser can block a response that is not sent as an accepted JavaScript type. For a CSS file, it can block a response that is not sent as text/css. For other responses, the browser uses the declared type instead of trying to reinterpret the content.
The header does not fix a wrong Content-Type. If a JavaScript file is sent as plain text, nosniff can stop it from loading. That failure is useful because it points to a server, cache, or file-delivery problem that needs correction.
⚠️ Note: This header lowers one content mix-up risk. It does not remove harmful code, patch an unsafe plugin, validate uploads, protect an admin account, or replace a firewall. Other headers such as X-Frame-Options address different browser behaviors.
Check before changing anything
Inspect the response that visitors receive before editing a file or installing a plugin. This prevents duplicate rules and shows whether another layer already adds the header.
Inspect the public page response: Open a terminal and run the command below, replacing the example address with your site.
curl -sI https://example.com/Look for this exact line:
X-Content-Type-Options: nosniffInspect sample files as well: Open your browser’s Developer Tools and select the Network panel. Reload the page. Check the document, one CSS file, and one JavaScript file. The homepage may pass through WordPress while those files come directly from the web server or a content delivery network (CDN). A CDN is a service that caches and sends files to visitors.
Check the visitor-facing layer: If your host uses page caching, a proxy, or a CDN, inspect the public URL after it passes through that service. A proxy is a server that forwards requests to another server. A setting in a host panel or plugin screen does not prove that the browser receives the header.
Choose the right place to add it
Use the layer that serves the response you want to cover.
- Use Apache settings when Apache serves your site: The rule can cover more than WordPress pages. You need access to the server settings or the site’s .htaccess file.
- Use NGINX settings when NGINX serves your site: NGINX has no .htaccess file, so the rule belongs in its server settings.
- Use WordPress code when WordPress is your only control point: This works for pages processed by WordPress. It may miss files served directly, cached pages, and files served before WordPress runs.
- Use a maintained header plugin when you have admin access only: This avoids editing server files. It adds another setting to maintain. It can also overlap with host, cache, or security-plugin rules.
Server or CDN settings are usually the broadest option. If you are unsure which web server your host uses, ask the host before changing a server file.
Add it with Apache
Apache is the web server used by many WordPress hosts. Its .htaccess file is a per-folder server settings file, not a WordPress feature that works on every host.
Back up the active file before editing: Keep a current backup and a way to restore the previous file. A spelling or formatting error can cause a server error or affect existing rewrite rules. The file may be hidden in your host’s file manager and is often in the site’s main site folder. See BlogVault’s WordPress .htaccess guide for the same backup-and-rollback precaution.
Add the guarded Apache rule: Apache needs its mod_headers component to change response headers. If it is available, add this to the matching server settings or .htaccess file.
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>Reconcile existing header rules first: Do not add a second rule if a plugin, host, cache, or CDN already sends this header. Duplicate values can make the final response unclear.
Apply the change through your host: Save the file and use the host’s normal process to apply the settings. On shared hosting, use the file manager only if the host supports this rule. If the site shows a server error, restore the backup before investigating further.
Add it with NGINX
NGINX uses server sections instead of .htaccess. If your host manages NGINX, ask support to add the rule or use its custom-header setting.
Add the NGINX rule in the correct section: A typical starting point is the site’s server section or a URL-specific location section.
add_header X-Content-Type-Options "nosniff" always;The word always asks NGINX to add the header for success, redirect, and error codes. NGINX also has inheritance rules, which decide whether a nested section keeps the settings from the section around it. If a nested location has its own header rule, it may stop inheriting rules from the surrounding block.
Validate and reload through the documented process: Test the settings before reloading them. Do not run NGINX commands on shared hosting where you do not manage the server. Then inspect the public response, including a page and a file.
🛠️ Note: Apache and NGINX do not apply headers in exactly the same way. A rule that works on the homepage may still miss a file, redirect, or error response.
Add it through WordPress
Use a WordPress-level method when the response is processed by WordPress and you cannot change the web server. A small site plugin is usually a better home for the code than a theme file because changing themes can remove it.
Add the header through the WordPress response hook: A hook is a WordPress extension point. The send_headers hook lets WordPress add a header before it sends a response.
add_action( 'send_headers', function () {
if ( ! headers_sent() ) {
header( 'X-Content-Type-Options: nosniff', true );
}
} );If WordPress reports a headers already sent error, fix the earlier output before relying on this hook.
Check the coverage before relying on this method: Apache or NGINX may serve CSS, JavaScript, images, uploads, and downloads without loading WordPress. A full-page cache or CDN may also serve a saved response before PHP, the language WordPress runs on, starts. Those responses may not receive a header added by this hook.
Choose a plugin with current support when code is not practical: A maintained header plugin can provide an admin screen for this setting. Check its recent support, way to undo changes, and documentation before installing it. Review other security and caching plugins for overlapping rules. Then verify the public response instead of trusting the plugin screen.
Verify the important paths
Adding the rule is only half the job. Check the responses visitors actually receive.
Check normal and directly served responses: Inspect an HTML page, one CSS file, and one JavaScript file. Each response should contain the header and the correct Content-Type for that file.
Check unusual responses when your site uses them: Review an upload or download endpoint, a redirect, a 404 page, and a cached or proxied URL. You do not need every possible URL, but you should check the paths that matter to your site.
Check important user actions: Load the public site and sign in to the WordPress dashboard. Submit a form. Complete checkout or another key action if your site has one. A green scanner result is not enough if a file or customer journey is broken.
Confirm the exact result: The public response should contain one deliberate header with this value:
X-Content-Type-Options: nosniffIf a CSS or JavaScript response has nosniff but the wrong content type, fix the server’s file-type rule. Do not remove the header just to hide the error.
Fix common problems safely
Trace a missing header through the delivery path: Confirm that the change was saved and applied. Then check the cache, CDN, host settings, and nested server rules. Purge the relevant cache and inspect a fresh public response.
Remove the cause of duplicate values: A duplicate can come from WordPress, a plugin, the hosting server, or a CDN. Choose one deliberate control layer. Remove or replace the other rules.
Restore a broken site before testing again: If an .htaccess change causes a server error, restore the backup or use the host’s recovery method. Then confirm that mod_headers and the rule are available before trying again.
Repair a blocked file instead of turning off protection: If the browser console shows that a CSS file or script was blocked, compare its listed type with the file it should serve. Correct the file-type rule, URL rule, or cache response.
Add the rest of your security controls
X-Content-Type-Options is one browser-facing security measure. It does not replace updates, strong passwords, two-factor login security, limited user permissions, safe uploads, or tested backups. A browser source policy can also limit where scripts and other page files load from.
A WordPress security plugin can add broader protection. MalCare, for example, provides a WordPress firewall, malware scanning and removal, and bot protection. Those controls address malicious requests and compromised files, which this response header cannot. They also do not make an incorrect content type safe, so keep the header and fix delivery problems separately. Keep backups before making security changes.
🔒 Note: Do not copy a large bundle of security headers without testing it. Other headers can affect forms, embeds, scripts, login pages, and checkout.
Conclusion
Adding X-Content-Type-Options: nosniff makes browsers respect the content type your site sends. Inspect the public response first. Add the rule at the layer that serves it. Then test pages, files, redirects, errors, and cached routes.
Keep the header as one part of a wider WordPress security maintenance checklist. Fix incorrect file types instead of disabling nosniff. Keep a recovery path before changing server files. Use a security plugin when you need protection that a response header cannot provide. For a broader recovery plan, see WP Remote’s WordPress backup and restore guide.
