Deutsch
|
English

CONTENTSECURITYPOLICY - Detailed description

FM-Portal

IC2874
Administrator
FM-Portal

Overview

Parameter:CONTENTSECURITYPOLICY
Category: Custom Default
value: "default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob: *.mapbox.com *.etask.de alcdn.msftauth.net login.microsoftonline.com wss://*.etask.de;"
Product: eTASK.Other (Custom)


What does this parameter do?

This parameter implements the "Content Security Policy" (CSP) security measure. CSP is an HTTP header that tells the browser which resources (JavaScript, CSS, images, fonts, etc.) may be loaded from which sources. This protects against cross-site scripting (XSS) attacks, code injection, and other web-based attacks by blocking unwanted scripts.


What is this parameter used for?

  • Protection against cross-site scripting (XSS) attacks

  • Control over permitted resource sources (scripts, styles, images)

  • Prevention of code injection attacks

  • Restriction of inline script execution and eval()

  • Whitelist-based security architecture for external resources

  • Protection against unintentional loading of malicious content


Technical Details (for Administrators)

Format: CSP directive (string)
Default value:

Explanation of the default value:

  • default-src = Fallback rule for all resource types

  • 'self' = Resources from the same domain allowed

  • 'unsafe-inline' = Inline JavaScript and inline CSS allowed (required for Ext.NET)

  • 'unsafe-eval' = Use of eval() allowed (required for Ext.NET)

  • data: = Data URIs allowed (Base64-encoded images, etc.)

  • blob: = Blob URLs allowed (for dynamically generated content)

  • *.mapbox.com = Mapbox maps (geodata visualization)

  • *.etask.de = eTASK-specific resources and APIs

  • alcdn.msftauth.net = Microsoft authentication (Azure AD)

  • login.microsoftonline.com = Microsoft Login

  • wss://*.etask.de = WebSocket connections to eTASK servers

Special Outlook add-in rule:

For paths under /neon/app.Etask/pub/OAI/ an extended CSP is used that allows additional Microsoft domains:

Important notes:

  • The CSP is sent as an HTTP header content-security-policy .

  • Activation is performed via the CONTENTSECURITYPOLICYAKTIV parameter

  • Line breaks are automatically replaced by spaces

  • WARNING: Changes made without technical expertise may render the portal inoperable

  • Test mode available (see CONTENTSECURITYPOLICYAKTIV)

Interaction with other parameters:

  • CONTENTSECURITYPOLICYAKTIV: Controls activation (0=off, 1=on, 2=report-only)

  • XFRAMEOPTIONS: Additional security measure against clickjacking

  • CONTENTTYPEOPTIONSNOSNIFFACTIVE: Prevents MIME type sniffing

  • XPERMITTEDCROSSDOMAINPOLICIES: Protection against cross-domain embedding


When should you change this value?

Leave the value at the default if:

  • You do not embed any special external resources

  • You lack expertise in CSP configuration

  • Your portal is functioning normally

Adjust the value if:

  • Special JavaScript libraries are loaded from CDNs

  • Custom developments require external resources

  • Security policies require stricter CSP rules

Warning - Never change without:

  • Comprehensive knowledge of CSP syntax and directives

  • Testing in a development environment

  • Use of Report-Only mode (CONTENTSECURITYPOLICYAKTIV = 2) for testing

  • A backup of the original configuration

  • Support from experienced web security experts


Important Notes

  1. Functional testing is
    mandatory after any changes Any change to the CSP can cause scripts, styles, or external resources to be blocked, rendering the portal inoperable. Test all functions thoroughly!

  2. Use Report-Only
    Mode Before activating a new CSP, set CONTENTSECURITYPOLICYAKTIV to 2. This ensures that violations are only logged but not blocked. Check the logs and adjust the CSP.

  3. 'unsafe-inline' and 'unsafe-eval' required
    The eTASK portal is based on Ext.NET, which uses inline scripts and eval(). DO NOT remove these directives, as this will render the portal completely inoperable.

  4. Monitor the browser
    console CSP violations are displayed in the browser developer console (F12). Monitor this for changes to identify blocked resources.

  5. Use wildcards
    sparingly Avoid overly broad wildcards (e.g., *), as these significantly weaken security. Be as specific as possible.

  6. Documentation Required
    Document every change to the CSP, including the reason and date. This helps with future issues and updates.


Security

Does changing this parameter affect security?

Yes, this parameter is a key security mechanism with significant implications.

Positive security aspects (when configured correctly):

  • XSS protection: Prevents the execution of injected scripts

  • Code injection protection: Blocks unwanted external scripts

  • Data exfiltration protection: Controls where data can be sent

  • Whitelist principle: Only explicitly permitted sources are accepted

  • Defense-in-depth: Additional layer of security alongside other measures

Security risks due to incorrect configuration:

  • Too permissive: Wildcards such as * or https: render CSP ineffective

  • Missing domains: Blocks legitimate functions

  • Too restrictive: Portal no longer works

Recommended security best practices:

  1. Use test mode: Test new CSPs first with CONTENTSECURITYPOLICYAKTIV=2

  2. Principle of minimalism: Allow only domains that are actually needed

  3. Regular review: Check CSP with every portal update

  4. Monitoring: Monitor CSP violations in the application log

  5. No compromises: Critically review external services before adding them to the CSP

Recommendation: The default CSP is optimal for most installations. Change it only if absolutely necessary, and test extensively. While insecure configurations may keep the portal functional, they no longer provide protection against XSS attacks.


Practical example

Initial situation: Your organization wants to integrate Google Analytics into the eTASK portal to collect usage statistics. After integration, the browser console shows CSP violations: Google Analytics scripts are being blocked.

Problem: The current CSP does not allow resources from *.google-analytics.com or *.googletagmanager.com. The Analytics integration does not work.

Solution - Step by step:

Step 1: Identify the required domains

Check the browser console (F12) and identify all blocked resources: - https://www.google-analytics.com/analytics.js - https://www.googletagmanager.com/gtag/js

Step 2: Extend the CSP

Expand the CONTENTSECURITYPOLICY:

Old configuration:

New configuration:

Step 3: Test in report-only mode

  1. Set CONTENTSECURITYPOLICYAKTIV = 2 (Report-only)

  2. Enter the new CSP

  3. Test the portal over several days

  4. Check the application log for CSP violations

  5. Ensure that all functions are working

Step 4: Activation

If no issues arise: 1. Set CONTENTSECURITYPOLICYAKTIV = 1 (Enabled) 2. Continue monitoring the browser console and logs 3. Document the change

After the change:

  • Google Analytics scripts are loaded

  • Usage statistics are being collected

  • The browser console no longer shows any CSP violations

  • All portal functions work normally

  • Security level remains high (only specific domains added)

Result: The integration is functional, and the CSP continues to protect against unwanted scripts. Only the explicitly required domains were added, not a broad wildcard.


Recommended setting

For standard installations: Keep default value

Reason:

  • Covers all standard eTASK functions

  • Enables Mapbox maps, Azure AD login, WebSockets

  • Balances security and functionality

  • Has been extensively tested

  • Regularly updated by eTASK

Exceptions (customization required):

  • Custom developments: Proprietary external resources or APIs

  • Third-party integrations: Analytics, Monitoring

  • Specialized CDNs: JavaScript libraries from other CDNs

  • Stricter security policies: Compliance requirements necessitate more restrictive CSP

Note the following when making changes:

  1. Document: Document every change with justification

  2. Testing: Test extensively in report-only mode

  3. Be specific: No wildcards such as https: or *

  4. Backup: Back up the old configuration

  5. Monitoring: Monitor logs after activation

Understanding CSP directives:

Before you modify the CSP, familiarize yourself with the most important directives:

  • default-src: Default for all resource types

  • script-src: Only for JavaScript (overrides default-src)

  • style-src: Only for CSS (overrides default-src)

  • img-src: For images only

  • connect-src: For AJAX, WebSocket, EventSource

  • font-src: For fonts

  • frame-src: For frames and iFrames

Important: Only change CONTENTSECURITYPOLICY if you understand the CSP specification and can assess the consequences. If in doubt, consult a web security expert or eTASK Support.

War dieser Artikel hilfreich?