I have seen enough questions on how to protect parameters passed to reports to warrant a blog entry.


Let’s say if you want to integrate a report containing HR data in your application. Let’s assume the data in the HR database is keyed by the EmployeeID field.

Your application will figure out the value of EmployeeID for the current user, and you could pass EmployeeID as a report parameter that’ll drive its queries.


The problem with this approach is that your users could change the parameter and pass in another EmployeeID, which leads to unwanted information disclosure. You can try to hide the parameter, so it will not show up in the report viewer toolbar, or not show the toolbar at all, but parameter values will still show up in the URLs generated in the report.

Then you may start thinking about making the values random – so they’re harder to guess, or encrypt their values, etc, etc…

The truth is, you should never make security decisions based on report parameters. Report parameters are eminently spoof-able, hiding them will not work for sophisticated users, and custom-made encryption are seldom strong enough to withstand a serious hacker.

Instead of using parameters, base your security decisions on User!UserID. UserID is populated as the result of the authentication mechanism so it is inherently more reliable than parameters.

In the example above, you can add code in your report that retrieves the EmployeeID based on UserID.



If you can’t establish a relationship between your user’s Windows accounts and your report data, you can implement a custom authentication extension as described here. The value for UserID will then be determined by your custom auth extension.