Skip to main content

General Security Considerations

  • 5 minutes to read

This topic documents how to mitigate security risks when deploying a DevExpress powered web-based reporting application.


If you have not yet done so, be sure to review the following help topic: Reporting - Security Considerations.

Cross-site Scripting (XSS) Security

  • Client-side reporting controls are protected against script injection. Property values are always encoded when they are exported to HTML.

  • Web End-User Report Designer

    A user can add a “javascript:” prefix to the XRControl.NavigateUrl property value. This allows the link to execute JavaScript code on the client and leaves other users vulnerable to cross-site scripting (XSS) attacks.

  • Web Document Viewer

    The Document Viewer’s initial settings do not allow JavaScript code execution within the XRControl.NavigateUrl property values. If your application relies on scripts in URLs, use the AllowURLsWithJSContent property to enable URLs with JavaScript in the ASP.NET Web Forms, ASP.NET MVC, and ASP.NET Core platforms.

You can also enable a Content Security Policy (CSP) in your application. The Content Security Policy (CSP) is an additional layer of security built into most modern browsers. It allows the browser to recognize and mitigate certain types of risks, such as Cross Site Scripting (XSS) and data injection attacks. These attacks include, but are not limited to, data theft, page spoofing, and malware distribution.

For more information on the Content Security Policy for DevExpress Reporting components, refer to the following topic: Content Security Policy.

Protect Sensitive Information

Ensure Authorized Access

For access control purposes, all operations can be classified by the object that the document viewer processes within a specific operation. The objects are:

  • Reports
  • Documents
  • Document export results.

To implement authorized access to these objects in a reporting application, review the following help topic: Authorized Access to Reports and Documents in a Web Reporting Application.

Avoid Sensitive Data Exposure Through Report URL

A report URL (report string identifier) is a string that contains a report name, report parameters, and may contain other information. A client method that opens a report will send this string to the server. The string may reveal sensitive information, such as an application’s internal structure.

Make certain that the report URL does not contain sensitive information. Implement custom report name resolution services to detect and remove unnecessary information from report string identifiers. The following services are available:

A recommended service for the Document Viewer and Report Designer. The primary advantage of IReportProvider service is that it can be attached to reports created at runtime. IReportProviderAsync uses asynchronous operations.
This service is called when no other report name resolution services are available. It is designed to obtain reports (stored in our REPX format) from external storage (a file or a database). Note that the GetData method returns a serialized report. If you use the GetData method to specify the default parameter value for a loaded report, set the Value property to the parameter value.

The following services have a higher priority than the previously mentioned services, although the scope of their use is limited.


Allows you to parse a report name, create a report instance, and return it to the calling method. If you have a parameterized report, you can specify parameters in the report name passed to the service and use parameters within the report’s constructor.

The IWebDocumentViewerReportResolver service is Intended for use only with the Web Document Viewer, and enables you to implement name resolution differently in the Report Designer and Document Viewer. The XRSubreport control does not use this service.

The IWebDocumentViewerReportResolver service does not support asynchronous mode.

Ensure Safe Image Loading from URL

The XRPictureBox.ImageUrl property does not accept the “file://“ protocol out-of-the-box (it only accepts ‘http://‘, “https://“ and “ftp://“ protocols). The same rule applies to the XRRichText report control for images in the IncludePicture fields.

To use the “file://“ protocol in image URLs, use the DevExpress.Security.Resources.AccessSettings class to apply access rules that enable image loading from specified locations.

Protect Passwords on the Client Side

Passwords for PDF and Excel files with other export options are always passed in a POST request (to exclude them from browser history).

If users share a report, passwords specified for PDF and Excel files are not exposed in the Web Document Viewer. A user who has access to documents exported by other users cannot bypass password protection.

Call the EnablePassingExportOptionsPasswordsToClient method at application startup to pass PDF/Excel passwords (specified in the Report Designer) to the Web Document Viewer on ASP.NET Web Forms & MVC and ASP.NET Core platforms.

Protect Passwords on the Server Side

The report definition (REPX) file stores PDF/Excel passwords in plain text. Ensure that only trusted parties have access to report definition files.

Disable Report Scripts


Report scripts are insecure. Use Expressions or ExpressionsAdvanced data binding modes instead. For more information, review the following help topic: Data Binding Modes.

For security reasons, the Web End-User Report Designer is initially configured to prohibit script execution, and view and edit operations. For information on how to enable scripts in the Web End-User Report Designer, review the following help topic: Scripts Security.

Safe Deserialization

DevExpress controls automatically detect potentially unsafe data types and block their deserialization to improve app security. The NonTrustedTypeDeserializationException is thrown if a reporting control attempts to load an unsafe data type. Review the following help topic that describes serialization/deserialization practices specific to Reporting components:

Reporting - Safe Deserialization