BC 7.3 introduces a new feature called the content domain that is designed to improve security by mitigating cross site scripting (XSS) attacks originating in authentic server content. This note aims to explain the feature and also to explain the implications for those clients who choose to host their BC server under a non-withbc.com domain name.

What does the content domain do?

In use, the content domain is a separate host name, based on the main server name that is used purely to access document content as opposed to browsing the BC server and carrying out actions.

For example, normal login and browsing of the server would involve pointing your web browser at customer.withbc.com and all subsequent requests are made to that server name too. Previously, requests to access document content – to download or view a file – were also made to the same host name.

Because of the trust/security model that the web browser uses, that document content is considered to be as trusted as any other content served by the application. This opens up the opportunity for a malicious user to insert malicious content that could theoretically access session information and allow impersonation of a user. BC already implemented several mitigations against this kind of attack including session expiry and notification of sessions switching source IP but the new approach eliminates that issue by addressing the root cause.

By providing a separate host name (typically customer-content.withbc.com) from which all file data is served, there is no opportunity for that content to exploit the browser security model and maliciously obtain session information.

Authentication on the content domain is handled by short lived, one-off authentication tokens which are useless outside of the intended purpose of authorising a single download of whatever document has been requested.

Users will notice almost no difference in day to day usage as the only change is to the document’s URL which is usually not visible when carrying out a normal download. Existing links to documents are automatically redirected to the new URL.

Implications for customers

There are three areas where actions may be required from GroupBC customers and the users of the customers’ servers.

  • Proxy and Firewall – allow equivalent access to the additional hostname
  • DNS – if the customer is responsible for DNS, a new record is required
  • SSL – if the customer is responsible for SSL certificates a valid cert for the additional hostname is required

Proxy and Firewall

In most cases where a customer’s users have unrestricted Internet access, no further action will be required. But for those customers who have put in place specific proxy server or firewall rules to allow access to the BC server then equivalent rules will need to be put in place for the additional content serving hostname. This additional hostname will typically point to the same IP address as the main server name and may be configured as a DNS CNAME record. This may negate the need to alter the proxy or firewall rules if they have been implemented by reference to IP rather than by DNS name. Note that in general we would recommend referencing services by DNS name to avoid issues due to IP changes in the future.


For the typical customer for whom GroupBC manages the DNS records associated with the BC server, no action is required.

For those customers who have a custom server name on their own domain and for whom GroupBC do not manage the DNS, an additional hostname will need to be added to allow access to the content domain.

We would suggest that for a BC server with hostname: <host>.<customer>.com that the content domain is of the form: <host>-content.<customer>.com

This host can be implemented as a CNAME pointing to the original BC server name as they will be implemented on the same server IP on the server side.


For the typical customer for whom GroupBC manages the SSL/TLS certificate associated with the BC server, no action is required.

For those customers who have a custom server name on their own domain it would be usual for an SSL certificate to be in place that has been purchased and verified through the customer’s internal team. Either an additional certificate will be required that matches the additional hostname or it may be possible to amend the existing certificate and combine the two names via a “Subject Alternative Name” (SAN) certificate. If you are uncertain about this then please talk to your certificate supplier. As usual, GroupBC can supply a CSR upon receipt of the details you wish the certificate to contain.