Security Best Practices
The article discusses general and reporting-specific security practices. While the recommendations may be necessary to keep your applications embedding Telerik Reporting secure, they may not be sufficient. The article should not be regarded as a complete and comprehensive security guidance.
General Security Considerations
Configuration Settings
The suggestions in this section are the responsibility of the developer embedding Telerik Reporting in a custom application.
- Run your applications hosting the Telerik Reporting REST Services and Web Report Viewers under HTTPS protocol and with the CORS enabled at the minimum required level.
- Avoid the Unsafe Code in your projects and their references.
- Consider implementing Rate Limiting in your Reporting Services to limit network traffic and prevent bad agents from exhausting system resources.
Reporting Specific Considerations
Report Definitions
- The Report Definitions gets instantiated by the Reporting Engine in runtime. The developer should ensure they come from trusted sources and don't contain malicious code.
- The Type report definitions are instantiated with reflection from the provided assembly. The advice from the section Extending Telerik Reporting is valid for these reports. Note that the assemblies with Type reports don't require registration in the assemblyReference of the configuration. It is the responsibility of the developer to ensure they don't threaten the environment.
- The declarative report definitions (TRDP, TRDX, and TRBP files) describe the report layout with XML code. The Reporting Engine unpackages or deserializes them to make the required Telerik.Reporting.Report instance. The developer should ensure no content may result in malicious executable code that may result in a security breach.
-
The Reporting Engine fetches the data from the DataSource components based on its properties. For example, the SqlDataSource provides a connection string, data provider, and a command, which may be an inline query or stored procedure name. The connection is delegated entirely to the specified provider and relies on the connection string. Our recommendation:
- use data connections with the least necessary permissions
Data is fetched by the data provider by executing the command. Ensure the user doesn't have permissions, for example, to delete information from the data tables.
- do not include connection strings and credentials in report files
Use named/shared rather than embedded connection strings. The Reporting Engine will resolve them from the application configuration.
Reporting Services
- The Telerik Reporting REST Service is a Web API application. Use the Microsoft recommendations ASP.NET Core security topics to ensure it is secure.
- The service is represented by the abstract ReportsControllerBase class. Its methods are not authorized. They are virtual and it is your responsibility to authorize the Reporting REST API defined in the custom ReportsController inheriting the ReportsControllerBase.
-
The requests for resources are marked with the AllowAnonymous attribute by design. For that reason, the Report Viewers won't add authenticationToken to these requests. If you need to authenticate the whole Web API of the Reporting REST Service, you need to add the header with a custom approach, for example, as explained in the following resources:
Extending the Reporting Engine
Telerik Reporting lets you extend its built-in functionality with custom code, for example by introducing Custom User Functions, Custom Aggregate Functions, Event Handlers and ObjectDataSources. The Reporting Engine invokes the custom functionality with reflection. The allowed assemblies should be whitelisted in the configuration of the application hosting the Reporting Engine as explained in the articles assemblyReferences Element, TypeReferences, and typeValidation. The entire responsibility for registering the custom assemblies and the security of their code is delegated to the developer.
Use only trusted assemblies that are signed with a public key token (see Assembly (CLI)) and cannot be replaced when extending the Reporting functionality in your projects, avoiding remote code execution and other malicious actions.
Report Viewers
Don't expose sensitive information when working with the Report Viewers. Consider the following:
-
URL taking the user to the Report Viewer
Don't pass the report identifier, parameter values, or other sensitive information as inline or query parameters as they become part of the URL.
-
Client-side ReportSource, for example, the HTML Report Viewer's reportSource.
The viewer's/client-side reportSource is sent to the service with the request. Avoid sending sensitive information with it. For example, you may pass the connection string to the report as a Report Parameter Value as explained in the KB article Change Connection String dynamically through a report parameter. The value will be sent in the body of the request, which may be insecure, especially when the application runs under HTTP.
When using HTTPS, the requests are encrypted and generally considered as secure. If you want an additional level of security, consider the ReportSource Resolver that resolves the client-side reportSource to a server-side one. For example, use as reportSource.report insensitive identifiers that may be resolved to the actual ones in the resolver.
Web Report Designer
Use Fine Tune the Customization in the Web Report Designer to limit the permissions per user.
Report Converters
When using the Report Converters provided by Telerik Reporting tool, you need to ensure the imported report definitions are safe and don't contain malicious code.