What is X-Content-Type-Options in WebSphere? (And How to Enable It)

If you are locking down an enterprise Java application hosted on IBM WebSphere Application Server (WAS), you have likely run a security scan (AppScan, SonarQube, etc.) that flagged a missing header: X-Content-Type-Options.

In the world of Apache, Nginx, or modern Node.js apps, fixing this is a one-line config change. But in the ecosystem of WebSphere, things are rarely that simple. You might be frantically searching for a “checkbox” in the Administrative Console that simply doesn’t exist.

This guide explains what this header actually does and provides the specific, technical steps to enable it in a WebSphere environment.

What is X-Content-Type-Options?

This HTTP response header is a security feature that stops a browser from trying to “guess” the file type of a resource.

The Problem: MIME Sniffing

Browsers are helpful—sometimes too helpful. If your server sends a file with Content-Type: text/plain, but the browser sees HTML tags inside it, the browser might decide,

“Hey, this looks like HTML! I’ll execute it as a script just in case.”

This behavior is called MIME Sniffing.

Hackers exploit this by uploading malicious scripts disguised as harmless files (like images or text files). If the browser sniffs the code and executes it, you have a Cross-Site Scripting (XSS) vulnerability.

The Solution: nosniff

By sending the header X-Content-Type-Options: nosniff, you are telling the browser: “I know what I am doing. If I say it is text, treat it as text. Do not guess.”

The WebSphere Challenge

Here is the “gotcha” that trips up many developers:

Traditional WebSphere Application Server (tWAS) does NOT have a simple custom property to enable this header.

For other headers, you might be used to adding properties like com.ibm.ws.webcontainer.disablexPoweredBy (to hide the server version) or com.ibm.ws.webcontainer.addStrictTransportSecurityHeader (for HSTS).

There is no equivalent property for X-Content-Type-Options in the traditional WAS Admin Console. If you try to invent one, it will simply be ignored.

To enable it, you must use one of the following three methods.

Method 1: The “IBM HTTP Server” Layer (Recommended)

In 99% of production environments, WebSphere sits behind an IBM HTTP Server (IHS), which is based on Apache. This is the easiest and most performant place to add security headers.

1. Locate your httpd.conf file (usually in /opt/IBM/HTTPServer/conf/).
2. Ensure the mod_headers module is loaded:ApacheLoadModule headers_module modules/mod_headers.so
3. Add the following line to your global config or specific <VirtualHost> block:ApacheHeader always set X-Content-Type-Options "nosniff"
4. Restart the HTTP server.

Method 2: The Servlet Filter (For Standalone WAS)

If you are not using a web server in front of WebSphere (e.g., internal testing or direct access), you must inject the header using a Java Servlet Filter in your application code.

1. Create the Filter Class:

import javax.servlet.*;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class SecurityHeaderFilter implements Filter {
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
            throws IOException, ServletException {
        HttpServletResponse response = (HttpServletResponse) res;
        // Add the header to every response
        response.setHeader("X-Content-Type-Options", "nosniff");
        chain.doFilter(req, res);
    }
    // init() and destroy() implementations...
}

2. Register it in web.xml:

<filter>
    <filter-name>SecurityHeaderFilter</filter-name>
    <filter-class>com.yourcompany.SecurityHeaderFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>SecurityHeaderFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Method 3: WebSphere Liberty Profile (The Modern Way)

If you are using the modern WebSphere Liberty, IBM has made this much easier. You can configure headers directly in the server.xml or httpEndpoints.xml file without writing Java code.

Add this inside your <httpEndpoint> block:

<httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080" httpsPort="9443">
    <headers>
        <add name="X-Content-Type-Options" value="nosniff"/>
    </headers>
</httpEndpoint>

(Note: exact syntax may vary slightly depending on your Liberty feature version, but the <headers> tag is the standard approach).

Summary

• What is it? A lock that prevents browsers from executing non-script files as scripts (MIME sniffing).
• The WebSphere Trap: Do not look for a com.ibm...addXContentTypeOptions property in the admin console—it doesn’t exist for traditional WAS.
• The Fix: Configure it at the IBM HTTP Server (IHS) level for the best performance and ease of management.

By correctly implementing nosniff, you close a subtle but dangerous door in your application’s security architecture.