How to configure Content Security Policy for FastReport .NET WEB reports

Content Security Policy (CSP) is a key tool for protecting web applications from XSS attacks, but its integration with reporting systems is often fraught with difficulties. In the latest versions of FastReport .NET WEB, the architecture of the client-side has been significantly reworked, which simplifies compliance with a strict CSP without losing report functionality. In this article, we will examine how to properly configure CSP for FastReport reports and take into account typical risks.

How CSP works and why it is needed

Content Security Policy (CSP) is a security mechanism or even a standard for web applications that allows you to control which resources (scripts, styles, fonts, images, connections, etc.) can be loaded and executed on a page. CSP is implemented through the HTTP header Content-Security-Policy or HTML meta tag.

The main goal of CSP is to prevent Cross-Site Scripting (XSS) attacks and the introduction of malicious code. The policy prohibits the execution of unsigned or unauthorized scripts, even if an attacker manages to inject a <script> tag into the page.

In addition, CSP can:

• Restrict the sending of data to third-party domains.
• Control the use of eval() and similar constructs.
• Block the loading of unwanted styles, fonts, or plugins.

Key CSP Directives

Key CSP Values

• 'self' — only the own domain (including scheme and port).
• 'unsafe-inline' — allow inline scripts and styles (use with caution).
• 'unsafe-eval' — allow eval() and similar constructs.
• 'nonce-{value}' — one-time cryptographic token.
• 'sha256-{hash}' — hash of the inline script/style content.
• data: — allow data: URLs (relevant for images).
• https: — allow any HTTPS sources.

Example of enabling CSP in ASP .NET Core applications:

app.Use(async (context, next) =>
{
	context.Response.Headers.ContentSecurityPolicy = "script-src 'self' 'unsafe-inline' 'unsafe-eval';style-src 'self' 'unsafe-inline'";
	await next();
});

You can also do this in the HTML markup:

<meta http-equiv="Content-Security-Policy" 
      content="default-src 'self';
               script-src 'self';
               style-src 'self';
               img-src data: https:;
               object-src 'none';">

Changes in the Client-Side Architecture of FastReport .NET WEB

In the latest versions of FastReport .NET WEB, the architecture of the client-side has been significantly reworked:

• JavaScript scripts have been moved to static files – no longer is it necessary to specify unsafe-inline for scripts.
• Styles for controls have become static CSS files – this simplifies the management of appearance.

Important note about inline styles in reports: styles generated for the content of report pages (tables, text, borders) remain inline. For correct display of the report, it is necessary to allow unsafe-inline in the style-src directive.

Moving JS and CSS to static files has not only provided compatibility with CSP but also the ability to override WebReport styles without changing the source files (e.g., through an additional CSS file with higher priority). Furthermore, the behavior has been expanded; now you can connect your own scripts, override methods, and add handlers. And, of course, caching has improved – the browser loads the static content only once.

Scenarios for Bypassing CSP and Ways to Protect Against Them

Despite the reliability of CSP, there are scenarios for bypassing it. Most of them are not related to the shortcomings of the standard, but to implementation errors.

1. Weak Browser Support

Internet Explorer supports CSP partially – it may ignore key directives. Modern browsers (Chrome, Opera, Safari, Firefox) work correctly.

Solution: Do not rely solely on CSP in outdated browsers – use additional security mechanisms.

2. JavaScript Inside Automatic iframe

When opening a text document or image, the browser may automatically create an iframe wrapper. This page does not have a configured CSP, which allows malicious code to be executed.

Solution: Configure CSP for all generated pages, including downloadable resources.

3. Lack of CSP on Error Pages (4xx, 5xx)

Developers often protect only working pages, forgetting about 404, 403, 500 errors. An attacker can inject a script into a frame with such a page.

Solution: Apply CSP globally – through middleware or a web server (Nginx, IIS, Apache).

4. Loading Scripts from File Sharing Services

Some sites use cloud storage (Yandex.Disk, Google Drive) as sources of content. An attacker can place a malicious file or script there.

Solution: Do not use 'unsafe-inline' and https: in script-src if this is not critically necessary. Instead, specify specific domains: script-src 'self' https://trusted-cdn.com;

Conclusion: Security, Flexibility, and Performance in the New Version of FastReport .NET WEB

Thus, the new version of FastReport .NET WEB allows you to safely use reports in applications with a strict CSP policy, minimizing exceptions such as unsafe-inline. At the same time, the developer receives:

• Security – protection against XSS attacks.
• Flexibility – easy customization of appearance and behavior.
• Performance – due to caching of static content.

Implement a strict CSP in your projects without compromising the functionality of reports.