Share via


Making a Service Available Across Domain Boundaries

Microsoft Silverlight will reach end of support after October 2021. Learn more.

Using Silverlight version 4 for cross-___domain communication requires guarding against several types of security vulnerability that can be used to exploit Web applications. Cross-site forgery is a class of exploits that becomes a threat when allowing cross-___domain calls. This exploit involves a malicious Silverlight control transmitting unauthorized commands to a third-party service, without the user's knowledge. To prevent cross-site request forgery, Silverlight allows only site-of-origin communication by default for all requests other than images and media. For example, a Silverlight control hosted at https://contoso.com/mycontrol.aspx can access only services on that same ___domain by default – for example https://contoso.com/service.svc, but not a service at https://fabrikam.com/service.svc. This prevents a malicious Silverlight control hosted on the https://contoso.com ___domain from calling unauthorized operations on a service hosted on the https://fabrikam.com ___domain.

To enable a Silverlight control to access a service in another ___domain, the service must explicitly opt-in to allow cross-___domain access. By opting-in, a service states that the operations it exposes can safely be invoked by a Silverlight control, without potentially damaging consequences to the data that the service stores.

Silverlight 4 supports two different mechanisms for services to opt-in to cross-___domain access:

  • Place a clientaccesspolicy.xml file at the root of the ___domain where the service is hosted to configure the service to allow cross-___domain access.

  • Place a valid crossdomain.xml file at the root of the ___domain where the service is hosted. The file must mark the entire ___domain public. Silverlight supports a subset of the crossdomain.xml schema.

For more information about cross-scheme access, see Network Security Access Restrictions in Silverlight.

To use a clientaccesspolicy.xml file to allow cross-___domain access

  1. Build a service that enables access by a Silverlight client. For more information about how to do this, see How to: Build a Service for Silverlight Clients.

  2. Create a clientaccesspolicy.xml file that allows access to the service. The following configuration allows access from any other ___domain to all resources on the current ___domain.

    <?xml version="1.0" encoding="utf-8"?>
    <access-policy>
      <cross-___domain-access>
        <policy>
          <allow-from http-request-headers="SOAPAction">
            <___domain uri="*"/>
          </allow-from>
          <grant-to>
            <resource path="/" include-subpaths="true"/>
          </grant-to>
        </policy>
      </cross-___domain-access>
    </access-policy>
    

    Alternatively, if you want to allow access from only one other ___domain, such as https://contoso.com, replace the <___domain uri="*"/> line within the <allow-from> element of the clientaccesspolicy.xml file above with the line <___domain uri="https://contoso.com"/>.

    To allow access to an HTTPS service from any Silverlight control hosted over HTTP application, you need to put the <___domain uri=”http://*” /> element inside your <allow-from> element.

    The valid values for the headers attribute are:

    1. the wildcard (“*”) - which allows all headers that have not been blacklisted

    2. a comma-separated list of allowed headers. These allowed headers can use a wildcard suffix, for example, “X-CUSTOM-*”.

    To enable the service for access over TCP sockets, add <socket-resource port="4502" protocol="tcp" /> to the <grant-to> element, where the 4502 is the port value where the service is hosted.

  3. Save the clientaccesspolicy.xml file to the root of the ___domain where the service is hosted. If, for example, the service is hosted in https://fabrikam.com then the file must be located at https://fabrikam.com/clientaccesspolicy.xml.

  4. Test that the access is enabled by invoking the service from the other ___domain.

To use a crossdomain.xml file to allow cross-___domain access

  1. Build a service that enables access by a Silverlight client. For more information about how to do this, see How to: Build a Service for Silverlight Clients.

  2. Create a crossdomain.xml file that contains the following configuration. The file must be configured to allow access to the service from any other ___domain, or it is not recognized by Silverlight 4.

    <?xml version="1.0"?>
    <!DOCTYPE cross-___domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-___domain-policy.dtd">
    <cross-___domain-policy>
      <allow-http-request-headers-from ___domain="*" headers="SOAPAction,Content-Type"/>
    </cross-___domain-policy>
    
  3. Save the crossdomain.xml file to the root of the ___domain where the service is hosted. If, for example, the service is hosted in https://fabrikam.com, then the file must be located at https://fabrikam.com/crossdomain.xml.

  4. Test that the service is enabled by invoking the service from the other ___domain.

Send comments about this topic to Microsoft.

Copyright © 2010 by Microsoft Corporation. All rights reserved.