DevExpress Reporting - Security Considerations
- 4 minutes to read
Safe Storage and Distribution
This section addresses the safe storage and distribution of report layouts and describes security best practices.
Possible risks include the leakage of sensitive data contained in serialized reports and the execution of malicious code injected into them by third parties. The following sections describe how to eliminate these risks:
Prevent Execution of Serialized Code
When you open reports from untrusted sources in Print Preview or Report Designer, malicious code embedded in those reports can cause uncontrolled execution. We address these security risks with the following methods:
Use XML Serialization
To prevent uncontrolled code execution on the client, Report Designer uses XML serialization to save report layouts and style sheets.
Important
We recommend that you do not change the default behavior and continue using XML serialization for saving reports.
Unlike the legacy CodeDOM serialization, XML is protected against injecting harmful code into a report’s definition and executing it on a client machine when deserializing such report.
We recommend switching to XML serialization instead if your application still uses CodeDOM serialization.
Validate on Load
End-User Report Designer (WinForms and WPF) displays the following warning when a user attempts to load a potentially unsafe report:
A report is considered unsafe if it or any of its subreports contain any of the following:
Review the following help topics for more information:
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
Disable Report Scripts
Regardless of which serialization mechanism was used for saving a report, it may still include executable code contained in report scripts. If you enable report scripts, users are at risk of running malicious code on their machines. In web applications, the risk is higher because scripts run on the server.
Desktop and web reporting applications have different initial security settings:
- WinForms and WPF Reporting enable unrestricted report script execution.
- Web Reporting disables script execution.
Note that the XtraReport.CreateDocument method causes unsupervised script execution on the server (web application) or on the client machine (desktop application) and can compromise security.
Important
We recommend that you disable script execution and use expressions instead.
For information on how to disable report scripts, review the following help topic: Scripts - Security Considerations.
Protect Sensitive Report Data
The following information can help you to prevent sensitive data exposure in report definitions:
Protect Data Source Information
Unlike published report documents, a report definition does not store the actual values from the report data sources.
A report definition contains only the data connection name - it does not include any sensitive information related to data connections. User credentials and connection strings are stored in the application configuration file.
Important
A report definition can contain information about the data source schema (as Base64-encoded text), which includes names of selected data source tables, views, and columns.
For more information on how to specify data connection settings at runtime, review the following topics:
- Specify Data Connection
- SqlDataSource - Best Practices for Managing Connection Settings in XtraReports
In web applications, reporting components encrypt certain data, such as connection parameters, and pass it to the client in encrypted form. Review the following help topic for more information: Data Access Security.
Protect Password Information
A report definition file stores PDF and Excel passwords in plain unencrypted text.
Once you specify passwords in the report’s ExportOptions, all PDF and Excel files created from this report automatically use these passwords. Unauthorized access to the original report definition that contains the passwords specified for the export parameters can compromise all PDF and Excel documents created from that report.
Important
Avoid default passwords for PDF and Excel exports and limit access to the report definition files that reveal those passwords and the PDF and Excel document repository.
Use Security Data Row Filters (Multi-Tenant Support)
Security Data Row Filters restrict access to the source data based on the user who is logged into the system. Security filters are part of the multi-tenancy application architecture. For more information, review the following help topic: Multi-Tenant Support (Row Filtering in Shared SQL Database).
Platform - Specific Security Guidelines
Review the following help sections for more information about security in reporting applications for different platforms: