CONTENTTYPEOPTIONSNOSNIFFACTIVE - Detailed description

Overview

Parameter:CONTENTTYPEOPTIONSNOSNIFFACTIVE
Category: Custom Default
value: 0 (disabled)
Product: eTASK.Other (Custom)

What does this parameter do?

This parameter enables an important security mechanism that prevents browsers from "guessing" the content type (MIME type) of files. When enabled, a special HTTP header is sent with every server response, forcing browsers to accept only the file type declared by the server. This protects against a specific type of security vulnerability where attackers hide malicious code in seemingly harmless files.

What is this parameter used for?

• Protection against MIME type confusion attacks

• Prevention of unexpected script execution in uploaded files

• Enforcing correct Content-Type declarations

• Increasing security for file uploads

• Supplementary security measure for Content Security Policy

• Implementation of modern web security standards (OWASP recommendations)

Technical Details (for Administrators)

Format: Integer (whole number)
Default value: 0

Valid values:

• 0 = Header is not added (security feature disabled)

• 1 = Header is added (security feature enabled)

Important notes:

• When enabled, the HTTP header X-Content-Type-Options: nosniff is sent with every response

• Browsers will then strictly adhere to the Content-Type sent by the server

• MIME-type sniffing (automatic file type detection) is completely disabled

• All resources must have correct Content-Type headers

• Supported by all modern browsers (Chrome, Firefox, Edge, Safari)

Interaction with other parameters:

• CONTENTSECURITYPOLICY: Defines additional security policies for allowed resources

• CONTENTSECURITYPOLICYAKTIV: Enables the Content Security Policy (0/1/2)

• XFRAMEOPTIONS: Protects against clickjacking attacks

• XPERMITTEDCROSSDOMAINPOLICIES: Prevents unwanted cross-domain embedding

How it works:

Without this header, browsers sometimes attempt to "guess" the actual content type of a file, even if the server sends a different Content-Type. For example: A server sends a file as an image (Content-Type: image/jpeg), but the file contains HTML code. Without the nosniff header, the browser could interpret the file as HTML and execute the scripts it contains—a security risk. With the nosniff header, the browser must respect the declared type and treat the file strictly as an image.

When should you change this value?

Set the value to 1 (enabled) if:

• You want maximum protection against XSS attacks

• You are implementing modern web security standards

• Security audits or penetration tests recommend enabling it

• You are already using or implementing Content Security Policy

• Compliance requirements mandate it

Keep 0 (disabled) if:

• You want to perform compatibility tests first

• There are known issues with older browsers

• Temporary troubleshooting is required

Recommendation: Enable this parameter

For production systems, this parameter should be 1 . The eTASK portal is prepared for this security measure and sets the correct Content-Type headers.

Important notes

1. Perform a test after activation After
   setting the value to 1, test all important functions, especially file downloads, file uploads, image display, and PDF previews. Generally, no problems should occur.

2. Check the browser developer console
   After activation, open the browser console (F12) and check for error messages such as "Refused to execute script because its MIME type is not executable." Such messages indicate incorrect Content-Type headers.

3. Correct Content-Type Headers Required
   Ensure that all resources have correct Content-Type headers. Examples: HTML=text/html, CSS=text/css, JavaScript=application/javascript, JSON=application/json, PDF=application/pdf, Images=image/png or image/jpeg.

4. No negative effects with Standard eTASK
   The Standard eTASK portal already sets correct Content-Type headers for all resources. Activation should therefore work without any issues.

5. Step-by-step activation possible
   If you are unsure, you can first activate the parameter in a test/development environment and test it thoroughly before putting it into production.

6. Troubleshoot, don’t disable
   If problems arise after activation, fix the cause (incorrect Content-Type headers) instead of permanently disabling the security mechanism.

Security

Does changing this parameter affect security?

Yes, this parameter has direct and significant security implications.

Positive security aspects (value 1 - enabled):

• XSS protection: Prevents harmless-looking files (e.g., images) from being interpreted as executable scripts

• Upload security: Protects against attacks involving malicious file uploads disguised as harmless file types

• MIME confusion defense: Blocks attacks that rely on browsers misinterpreting file types

• Defense-in-Depth: Additional layer of security alongside Content Security Policy and other measures

• Best Practice Compliance: Complies with recommendations from OWASP and the Mozilla Observatory

Note:

• Enabling this significantly increases security with minimal requirements

• Requires correct Content-Type headers for all resources

• Browsers must support modern standards (all current browsers do)

• May affect legacy applications with incorrect Content-Type headers

Security risks (value 0 - disabled):

• MIME sniffing enabled: Browsers can ignore content types declared by the server and interpret them on their own

• Upload vulnerabilities: Uploaded files containing hidden malicious code could be executed

• XSS attack surface: Increased risk of content-type-based cross-site scripting attacks

• Compliance issues: Not compliant with modern security policies and standards

Practical example

Initial situation: Your eTASK portal allows users to upload files (documents related to tickets, images of rooms, attachments). You want to ensure that uploaded files cannot be misused as malicious scripts, even if an attacker attempts to hide malicious code in seemingly harmless files.

Problem without activation:

An attacker creates a manipulated file: - File name: rechnung.jpg - Actual content: HTML with malicious JavaScript code - Uploaded to the portal - Server sends file with incorrect or ambiguous content type - Browser performs MIME sniffing and detects HTML content - Browser executes the JavaScript → Data is stolen or session is hijacked

Configuration: CONTENTTYPEOPTIONSNOSNIFFACTIVE = 1

Situation after activation:

Same attack attempt: - Attacker uploads rechnung.jpg with hidden HTML/JavaScript - Server sends file with correct content type image/jpeg - Browser additionally receives the header X-Content-Type-Options: nosniff - Browser strictly respects the declared Content-Type - Browser does NOT attempt to interpret the file as HTML - JavaScript is NOT executed → Attack is blocked - In the worst case, the user sees only a broken image

After the change:

• All resources are handled strictly according to their declared content type

• Uploaded files can no longer be executed as scripts

• The portal is significantly more secure against upload-based XSS attacks

• No functional limitations for correctly configured resources

• The browser developer console shows no errors (with correct server configuration)

Test checklist:

After activation, you should test: 1. File uploads of various types (PDF, Word, Excel, images) 2. File downloads and opening of uploaded files 3. Image display in tickets, room plans, and other modules 4. PDF preview functions 5. Crystal Reports generation and display 6. CSS and JavaScript resources of the portal

Expected result: All functions work as usual. The eTASK portal sets correct Content-Type headers, so no problems should occur. If errors do occur, this is due to incorrectly configured Content-Type headers, which should be corrected.

Recommended setting

For all installations:1(enabled)

Reason:

• Important and effective security measure against XSS attacks

• Reliably prevents MIME type confusion attacks

• No negative impact when Content-Type headers are correct

• Complies with best practices (OWASP, Mozilla Observatory, NIST)

• The standard eTASK portal is fully compatible

• Supported by all modern browsers

• Minimal effort, maximum security gain

• Easy to implement and test

Recommended for:

• Production systems: Essential for secure production environments

• Test/development environments: Should also be enabled for realistic testing

• External/public portals: Absolutely necessary for internet access

• All systems with file upload: Critical protection for upload functionality

• Systems subject to compliance requirements: Required for security certifications

Disable temporarily (set to 0) only for:

• Acute troubleshooting: Only to diagnose whether nosniff is causing a problem

• Legacy migration: During the transition phase, then reactivate immediately

• Known third-party issues: Only until resolved by the provider

Combination with other security measures:

For maximum security, combine this parameter with:

1. CONTENTTYPEOPTIONSNOSNIFFACTIVE = 1 (this parameter)

2. CONTENTSECURITYPOLICYAKTIV = 1 (enable CSP)

3. CONTENTSECURITYPOLICY = (configure an appropriate CSP policy)

4. XFRAMEOPTIONS = "sameorigin" (Clickjacking protection)

5. XPERMITTEDCROSSDOMAINPOLICIES = "none" (Cross-domain protection)

Activation checklist:

1. Set CONTENTTYPEOPTIONSNOSNIFFACTIVE = 1

2. Test file upload functions in modules

3. Test file download and display

4. Check image display in tickets, room plans, and documents

5. Test PDF generation and preview

6. Open the browser developer console (F12) and check for errors

7. Document the activation and the test date

If problems occur:

If problems occur after activation: 1. Open the browser developer console (F12) 2. Search for error messages containing "MIME type" 3. Identify the affected resources 4. Check the Content-Type headers of these resources 5. Correct incorrect or missing Content-Type headers 6. DO NOT permanently disable nosniff

note3a81cdea-6b58-43bb-9032-612883070759

Important: Address the root cause (incorrect Content-Type headers), not the symptom. The nosniff header should remain enabled, as it is an essential component of the security architecture.

Important: Address the root cause (incorrect Content-Type headers), not the symptom. The nosniff header should remain enabled, as it is an essential component of the security architecture.