Embedded SSRS report parameter not passing to analytics dash

BA/BI SQL Server Reporting Services (SSRS)
, , , , , , , ,
1

We’re embedding SSRS 2014 reports into our ERP analytics dashboard using iframes, but parameters aren’t syncing properly with the dashboard filters. When users select a date range or department filter in the main dashboard, the embedded report should update accordingly, but it stays static showing default values.

I’m passing parameters through the URL string in the iframe src attribute, and the URL looks correct when I inspect it. The SSRS report itself works fine when accessed directly through Report Manager with the same parameters. The issue only occurs in the embedded context.

Our setup uses cross-domain embedding (dashboard on app.company.com, SSRS on reports.company.com). Could CORS be blocking the parameter passing, or is there something specific about SSRS URL parameter syntax in iframe scenarios that I’m missing?

2

Thanks for the pointer. I checked the console and yes, seeing X-Frame-Options: SAMEORIGIN blocking errors. My URL format matches what you described. What’s the fix for the CORS issue? Do I need to modify something on the SSRS server configuration or is there a workaround on the dashboard side?

3

The proxy approach sounds interesting but might be overkill for our current setup. I’d like to try the rsreportserver.config modification first. Can someone provide the specific XML I need to add? Also, if I go that route, how do I specify which domains are allowed rather than opening it up completely?

4

Let me give you a complete solution addressing all three aspects of your issue:

1. SSRS URL Parameter Syntax for Iframes: Your iframe src should follow this exact pattern:


http://reports.company.com/ReportServer?/Analytics/SalesReport&rs:Command=Render&StartDate=2024-01-01&EndDate=2024-12-31&Department=Sales

Key points: Use /ReportServer not /Reports (web portal), include rs:Command=Render, use & between parameters, URL-encode special characters.

2. Iframe Embedding Limitations: SSRS 2014’s iframe restrictions come from the X-Frame-Options: SAMEORIGIN header. To modify this, edit rsreportserver.config and add to the <Service> section:

<Add Key="X-Frame-Options" Value="ALLOW-FROM https://app.company.com" />

Restart the SSRS service after changes. Note: ALLOW-FROM has limited browser support (deprecated in modern browsers).

3. CORS Configuration for Cross-Domain Access: For modern browsers, you need to remove X-Frame-Options and add Content-Security-Policy instead. In the same config file:

<Add Key="Content-Security-Policy" Value="frame-ancestors 'self' https://app.company.com" />

This provides better browser compatibility and security.

Dynamic Parameter Passing: In your dashboard JavaScript, update the iframe src dynamically when filters change:

function updateReport(startDate, endDate, dept) {

  const baseUrl = 'http://reports.company.com/ReportServer?/Analytics/SalesReport';

  const params = `&rs:Command=Render&StartDate=${startDate}&EndDate=${endDate}&Department=${encodeURIComponent(dept)}`;

  document.getElementById('reportFrame').src = baseUrl + params;

}

Testing Approach:

  1. First, verify the URL works directly in a browser (not in iframe)
  2. Check browser console for specific CORS/frame errors
  3. After config changes, test with a simple static iframe before adding dynamic parameters
  4. Use browser dev tools Network tab to confirm the correct URL is being requested

Important Security Considerations: Only whitelist specific domains you control. Never use frame-ancestors * in production. Consider implementing additional authentication checks in your SSRS reports to verify they’re being accessed from legitimate sources. If your organization has strict security requirements, the server-side proxy approach mentioned earlier is more secure than modifying CORS headers.

The combination of correct URL syntax, proper CORS configuration, and dynamic iframe src updates should resolve your parameter passing issues. Let me know if you hit any specific errors during implementation.

5

You’ll need to modify the SSRS server configuration. In SSRS 2014, you have to edit the rsreportserver.config file to allow cross-domain embedding. Look for the <Service> section and add custom HTTP headers. However, be careful with security implications - you’re essentially opening up your report server to embedding from other domains.

Alternatively, consider using the SSRS web service API to fetch report data and render it natively in your dashboard rather than using iframes. This gives you more control over parameter passing and avoids CORS issues entirely. The SOAP API in SSRS 2014 has Render methods that return report output.

6

For the config approach, you need to be on the SSRS server and edit C:\Program Files\Microsoft SQL Server\MSRS12.MSSQLSERVER\Reporting Services\ReportServer\rsreportserver.config. But honestly, SSRS 2014 doesn’t have granular domain whitelisting for X-Frame-Options. You can remove the restriction entirely, but that’s a security risk.

A better middle-ground: keep SSRS on the same parent domain. If your dashboard is at dashboard.company.com and SSRS at reports.company.com, they share the same root domain. You can set document.domain in JavaScript on both sides to enable communication. This works because they’re considered same-site even if not same-origin.

7

The cross-domain setup is likely your issue. SSRS 2014 has strict same-origin policies for embedded scenarios. Even if the URL parameters are correctly formatted, the browser may be blocking the refresh mechanism. Check your browser console for CORS errors - you’ll probably see something about X-Frame-Options or Content-Security-Policy headers being rejected.

For URL parameters in SSRS, the syntax should be: /ReportServer?/FolderName/ReportName&rs:Command=Render&Parameter1=Value1&Parameter2=Value2. Make sure you’re using & not ? after the report path for parameters.

8

I’ve dealt with this exact scenario. The iframe approach with cross-domain has too many limitations. What worked for us was implementing a server-side proxy. Your ERP dashboard backend makes the SSRS request on the same domain as the report server, then serves the content to the frontend. This way, the browser sees everything as same-origin, and you maintain full control over parameter injection.

The proxy can also handle authentication tokens more securely than exposing SSRS credentials in client-side JavaScript.