An Undefined Content-Type Header vulnerability occurs when a web application fails to specify a proper Content-Type header for HTTP responses. Without this critical header, browsers and intermediaries must guess the format of the returned content. This behavior, known as MIME type sniffing, can lead to misinterpretation of the content and enable various security risks, including Cross-Site Scripting (XSS), file execution, and content spoofing attacks.

When the server does not explicitly declare the content’s media type (e.g., text/html, application/json, text/plain, application/xml), the browser attempts to determine it based on the content itself. Attackers may exploit this by injecting malicious payloads into otherwise benign responses, causing the browser to treat them as executable HTML, JavaScript, or other active content.

Common attack scenarios:

• Reflected or stored XSS via JSON or text responses interpreted as HTML due to MIME sniffing.
• Malicious file uploads where an uploaded file is served back to users without an appropriate content type, enabling script execution.
• Open redirect or phishing vectors by causing browsers to treat arbitrary responses as rendered HTML.
• Content spoofing where attackers manipulate server responses to be rendered as different file types (e.g., HTML, SVG, XML, JavaScript).
• Cache poisoning where intermediary caches store misclassified responses used by multiple users.

Typical impacts include:

• Execution of arbitrary JavaScript in the user’s browser.
• Hijacking of user sessions and authentication tokens.
• Injection of phishing pages or deceptive content into legitimate responses.
• Bypassing security controls such as XSS filters or CSP.
• Persistent browser or proxy misinterpretation of cached responses.

Conditions enabling Undefined Content-Type vulnerabilities:

• Server responses without a Content-Type header.
• JSON endpoints returning data as raw text.
• Static files served without explicit MIME mapping.
• Proxy servers or CDNs configured to strip or override content types.
• Application logic that outputs dynamic content without proper headers.

Mitigation requires correctly defining the Content-Type for every response, enforcing strict MIME handling, and ensuring consistent server configuration.

1. Always Set Explicit Content-Type Headers
   Define appropriate Content-Type values for every endpoint and response:

   • text/html for HTML pages
   • application/json for API responses
   • text/css, image/png, etc., for static files
     Never allow the browser to infer the type.

2. Enable X-Content-Type-Options: nosniff
   Add the header:
   X-Content-Type-Options: nosniff
   This instructs browsers not to MIME-sniff and to strictly interpret the declared content type.

3. Correctly Configure Web Servers
   Ensure Nginx, Apache, IIS, and other servers define MIME types consistently.
   Avoid default configurations that serve unknown files as text/plain or omit the type entirely.

4. Define MIME Types in File Handling Logic
   When returning files (uploads, downloads, dynamic content), explicitly set the type based on safe logic—not user-provided file names.

5. Harden API Endpoints
   Ensure JSON, XML, and text API responses include proper headers.
   Example: Content-Type: application/json; charset=utf-8

6. Validate and Sanitize Uploaded Content
   Disable execution of uploaded files by serving them with safe content types such as application/octet-stream.

7. Implement Content Security Policy (CSP)
   Use CSP rules to reduce the impact of misinterpreted content.
   Example: default-src 'self'

8. Audit and Normalize Caching Behavior
   Ensure CDNs, proxies, and WAFs do not modify or remove Content-Type headers.

9. Security Testing
   Regularly test endpoints for missing or incorrect Content-Type through automated scanners and manual review.

10. Avoid Serving Mixed Content
    Ensure that no endpoint returns different types of content based on conditions without updating the header accordingly.

MDN – MIME Sniffing