Securing Reports and Resources

You can set security for individual reports and resources to control the degree of access that users have to these items. By default, only users who are members of the Administrators built-in group can run reports, view resources, modify properties, and delete the items. All other users must have role assignments created for them that allow access to a report or resource.

Role-based Access to Reports and Resources

To grant access to reports and resources, you can allow users to inherit existing role assignments from a parent folder or create a new role assignment on the item itself.

In most cases, you will probably want to use the permissions that are inherited from a parent folder. Setting security on individual reports and resources should only be necessary if you want to hide the report or resource from users who do not need to know that the report or resource exists, or to increase the level of access for a report or item. These objectives are not mutually exclusive. You can restrict access to a report to a smaller set of users, and provide all or some of them with additional privileges to manage the report.

You may need to create multiple role assignments to achieve your objectives. For example, suppose you have a report that you want to make accessible to two users, Ann and Fernando, and to the Human Resource Managers group. Ann and Fernando must be able to manage the report, but the Human Resource Managers members need only to run it. To accommodate all of these users, you would create three separate role assignments: one to make Ann a content manager of the report, one to make Fernando a content manager of the report, and one to support view-only tasks for the Human Resource Managers group.

Once you set security on a report or resource, those settings stay with the item even if you move the item to a new location. For example, if you move a report that only a few people are authorized to access, the report continues to be available to just those users even if you move it to a folder that has a relatively open security policy.

Mitigating HTML Injection Attacks in a Published Report or Document

In Reporting Services, reports and resources are processed under the security identity of the user who is running the report. If the report contains expressions, script, custom report items, or custom assemblies, the code runs under the user's credentials. If a resource is an HTML document that contains script, the script will run when the user opens the document on the report server. The ability to run script or code within a report is a powerful feature that comes with a certain level of risk. If the code is malicious, the report server and the user who is running the report are vulnerable to attack.

When granting access to reports and to resources that are processed as HTML, it is important to remember that reports are processed in full trust and that potentially malicious script might be sent to the client. Depending on browser settings, the client will execute the HTML at the level of trust that is specified in the browser.

You can mitigate the risk of running malicious script by taking the following precautions:

• Be selective when deciding who can publish content to a report server. Because the potential for publishing malicious content exists, you should limit users who can publish content to a small number of trusted users.
• All publishers should avoid publishing reports and resources that come from unknown or untrusted sources. If necessary, open the file in a text editor and look for suspicious script and URLs.

Mitigating SQL Injection Attacks in a Parameterized Report

In any report that includes a parameter of type String, be sure to use an available values list (also known as a valid values list) and ensure that any user running the report has only the permissions required to view the data in the report. When you define a parameter of type String, the user is presented with a text box that can take any value. An available values list limits the values that can be entered. If the report parameter is tied to a query parameter and you do not use an available values list, it is possible for a report user to type SQL syntax into the text box, potentially opening the report and your server to a SQL injection attack. If the user has sufficient permissions to execute the new SQL statement, it may produce unwanted results on the server.

If a report parameter is not tied to a query parameter and the parameter values are included in the report, it is possible for a report user to type expression syntax or a URL into the parameter value and render the report to Excel or HTML. If another user then views the report and clicks the rendered parameter contents, the user may inadvertently execute the malicious script or link.

To mitigate the risk of inadvertently running malicious scripts, open rendered reports only from trusted sources.

For more information about SQL injection attacks and mitigations, see Integrated Security and Elevated Permissions.

Securing Confidential Reports

Reports that contain confidential information should be secured at the data-access level, by requiring users to provide credentials to access sensitive data. For more information, see Specifying Credential and Connection Information. You can also secure a folder to make it inaccessible to unauthorized users. For more information, see Securing Folders.

See Also

Tasks

How to: Specify Stored Credentials for a Data Source (Management Studio)

Concepts

Integrated Security and Elevated Permissions
Creating, Modifying, and Deleting Role Assignments
Publisher Role
Role Assignments for Report Builder Access
Managing Permissions and Security for Reporting Services
Securing Shared Data Source Items

Other Resources

Working with Parameters in Reporting Services

Help and Information

Getting SQL Server 2005 Assistance

Change History