Reporting Security
- 4 minutes to read
This document addresses security implications related to storing and distributing report layouts and describes best practices to help you and your end-users understand reporting security.
Possible risks include leaking sensitive data contained in serialized reports and executing harmful code injected into them by third parties. The following sections describe how to eliminate these risks.
Prevent Execution of Serialized Code
Opening reports from untrusted sources in a Print Preview or Report Designer may trigger uncontrolled execution of harmful code injected into these reports:
Report Serialization
A report saved using a legacy serialization mechanism contains code that is compiled and executed when this report is loaded in a Report Designer. Injecting code into a report results in its uncontrolled execution on the client.
The latest DevExpress reports use XML serialization to save report layouts and style sheets created in Visual Studio and end-user Report Designers by default.
Important
We strongly 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.
When attempting to load a potentially harmful report, desktop End-User Report Designers (WinForms and WPF) display the following warning by default:
A report is considered dangerous on finding any of the following content in it (or in any of its subreports):
Tip
See the following documents to learn how to disable or enable loading these reports and hide this warning in your reporting applications:
- Ensure Safe Loading of Reports - WinForms
- Ensure Safe Loading of Reports - WPF
Report Scripts
Regardless of which serialization mechanism was used for saving a report, it may still include executable code contained in report scripts. Enabling report scripts on the client exposes your end-users to the risk of executing harmful code on their machines.
Important
End-user desktop and web reporting applications have different security settings by default:
- WinForms and WPF reporting applications enable unrestricted execution of report scripts by default.
- Script execution is disabled in ASP.NET reporting applications by default.
Calling the XtraReport.CreateDocument method to export a report or load its Print Preview triggers the uncontrolled execution of any code injected into the report’s scripts on the client machine. This code is executed in the application’s domain with full privileges granted to the application.
See Scripts Security for more information.
Protect Sensitive Report Data
Consider the following to prevent exposing sensitive information contained in report definitions:
Protecting Data Source Information
Unlike published report documents, a report definition does not store the actual values from a report’s data sources. It can only include general information about a report’s data sources and report elements’ data bindings.
A report definition only stores the data connection name by default. It does not include any sensitive information related to data connections (both the user’s credentials and connection string is saved to your application’s configuration file by default).
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.
You can handle the XtraReport.SaveComponents event to access and manage the list of serialized components.
Protecting Password Information
A report definition file stores PDF and Excel passwords in clear text.
After specifying these passwords in a report’s XtraReport.ExportOptions, all PDF and Excel files created from this report use these passwords by default.
Leaking the original report definition containing passwords specified for its export options exposes all PDF and Excel documents produced from this report using these passwords.
Important
Avoid specifying default passwords for a PDF and Excel export and restrict access both to report definition files exposing these passwords and the PDF and Excel documents’ storage.
Take the necessary measures to protect your reports and restrict access to their storage.