02. 06. 2025 Mattia Codato Development, Front-end, Icinga News, Icinga Web 2, NetEye, PHP

Content Security Policy (CSP) + NetEye 4.42

In the latest update to NetEye 4.42, we’re excited to announce the introduction of support for the Content-Security-Policy (CSP) header within the Icinga Web 2 interface. This enhancement plays a crucial role in strengthening your system’s defenses against cross-site scripting (XSS) attacks by controlling what resources a browser is allowed to load.

What is Content Security Policy (CSP)?

From the MDN Web Docs website:

Content Security Policy (CSP) is a feature that helps prevent or minimize the risk of certain types of security threats. It consists of a series of instructions from a website to a browser, which instruct the browser to place restrictions on the things that the code used by the site is allowed to do.

The primary use case for CSP is to control which resources, in particular JavaScript resources, a document is allowed to load. This is mainly used as a defense against cross-site scripting (XSS) attacks, in which an attacker is able to inject malicious code into the victim’s site.

A CSP can have other purposes as well, including defending against clickjacking and helping to ensure that a site’s pages will be loaded over HTTPS.

Enabling CSP in NetEye 4.42

To enable CSP within NetEye 4.42, administrators can navigate to Configuration > Application > General and toggle the Enable strict content security policy option. This setting ensures that all subsequent interactions with the Icinga Web 2 interface respect the CSP policies specified and defined by NetEye.

Ensuring Compatibility with Third-Party Modules

If third-party modules are installed on your system, it’s important to check their compatibility with the functionality of the CSP header before activating it. Modules that include scripts or inline styles may require updates to comply with CSP guidelines. Here’s how to ensure a smooth integration:

  1. Update the module: Most of the available open source modules have already been migrated by the community, so you only need to upgrade to the latest available version.
  2. Migrate the code: If the module is customized, or does not yet support the CSP header, it can be migrated by moving any inline styles to CSS classes. Alternatively, utilize nonces to allow specific inline styles under CSP.

Migrating Inline Styles with Nonces

As described in the official Icinga Web 2 blog, the Content-Security-Policy header prevents execution of any inline scripts and inline styles. But in some scenarios, CSS properties might change dynamically, so inline CSS is indispensable. In this case a style element for this part of the HTML document with a nonce attribute can be added with the corresponding styles configured.

The nonce value is a random secure code that is dynamically generated and acts like a one-time code. If you’re interested in knowing more about Content Security Policy, check out this link.

The nonce feature can be used in the PHP code as shown here:

$htmlDocument = new \ipl\Html\HtmlDocument();
$style = (new \ipl\Web\Style())->setNonce(\Icinga\Util\Csp::getStyleNonce());
$style->add('.header' => ['color' => 'white', 'background' => 'black']);
$html = \ipl\Html\Html::tag('h1', ['class' => 'header'], 'Inline Style');
$htmlDocument->add([$html, $style]);

For the entire NetEye 4.42 release, it’s possible to turn the CSP header on or off so that you can test whether all modules support this feature, yet at the same time ensuring a smooth migration by minimizing disruptions .

Conclusion and Future Updates

Moving forward, enabling CSP in NetEye 4.42 is not just a security enhancement but a necessary step towards preparing for future releases. Starting from NetEye 4.43, the strict CSP header will become mandatory, ensuring continued protection against XSS attacks.

In conclusion, the introduction of CSP support in NetEye 4.42 represents a significant advancement in our adherence to web security standards, providing administrators with enhanced control over their system’s vulnerability landscape.

These Solutions are Engineered by Humans

Did you find this article interesting? Does it match your skill set? Programming is at the heart of how we develop customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.

Mattia Codato

Mattia Codato

Software Developer - IT System & Service Management Solutions at Würth Phoenix

Author

Mattia Codato

Software Developer - IT System & Service Management Solutions at Würth Phoenix

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive