Content Security Policy Recommendations with OSLC

Content Security Policy is a useful tool to shape the security of any of your web applications. It is common in enterprise IT standards to enforce policies to limit the embedded content from remote sites. However, with OSLC, we intend to embed content from remote sites. So how do we manage the critical collaboration as well as security policies? For many organizations, this is the intersection of their OSLC needs and their existing CSP directives.

What is Content Security Policy (CSP)?

Content Security Policy is intended to mitigate injection attacks that look like trusted sources to the end-user. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

Security teams can define a policy that is enacted by a set of directives implemented in the Content-Security-Policy header of web traffic. These directives (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) are enforced at the browser level and make sure users are shielded from undesired behavior and content from websites.

Where is CSP Enacted?

The CSP headers can be injected from multiple sources within an enterprise. This includes the web application directly, the web-server, and/or a proxy/load-balancer. Your enterprise architecture will be critical for understanding and managing your OSLC deployment. This includes your application servers, the proxies, the networks, and the unique domains. It is often valuable to draw a simple diagram to be able to explain the features and nodes. It is almost always feasible with each node and proxy/passthru that we can add or remove content to the network traffic, including security headers.

How security headers are introduced depends on the technology. For example, if you happened to have a proxy in front of your OSLC application, it has the opportunity to modify the traffic it observes. If you are using HA Proxy, it is a simple instruction to rewrite content to include a header. The following would ensure that all http responses include a specific CSP directive.

http-response set-header Content-Security-Policy "frame-ancestors 'self'"

This simple statement can have a large impact on the way your enterprise behaves. It is enacting a specific policy on all traffic to control where content can be embedded. This is both powerful and challenging to manage. Following we will offer tools to understand CSP and its interaction with OSLC.

How does OSLC interact with CSP?

OSLC interaction with CSP is relatively tightly constrained. This because OSLC is focused on embedding content rather than embedding scripts. This means if the content is blocked in the browser, it is likely one of the following sources.

frame-src

A frame-src (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-src) directive will identify the valid sources that could be embedded into a frame/iframe. This allows a page to identify where other content can come from.

The most common default CSP with this directive is:

Content-Security-Policy: frame-src 'self';

This directive would instruct that for all iframe sources requested; they must all come from the same site (URL scheme and port).

Let’s consider an example. If this policy is set on a proxy in front of your Jira solution, it would be unable to embed content from any of its OSLC Friends. There would be no restriction, however, on the consumers embedding content from this Jira instance with this policy.

frame-ancestors

A frame-ancestors (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) directive will identify what sites can embed your content. This allows a page to identify how, or more specifically, where, it can be used.

The most common default CSP with this directive is:

Content-Security-Policy: frame-ancestors 'self';

This directive would instruct that only the current site could be used for all usages of content from this source.

Again, when using an example. If this policy is set on a proxy in front of your Jira solution, it would prevent any of its OSLC Consumers from embedding the content from Jira. There would be no restriction on Jira from embedding content from its Friends with this policy.

Policies

CSP Directives can be combined to create the entire policy. Each directive is separated by a ';' and has space-delimited lists of values.

For example, the following CSP:

Content-Security-Policy: frame-ancestors 'self'; frame-src 'self';

Would prevent any other site from using content from this page or using content from another site. It is very secure. However, if your IBM ELM environment is on https://myibm.elm.com/ and your Jira is on https://myatlassian.jira.com/, then there will be no embedding of content between the applications. Your OSLC Enterprise will be broken.

Recommendation Policy Pattern with OSLC

We have two possible suggestions for CSP Policies.

Option 1 is the simplest. It is perfectly reasonable and entirely secure not to have any content security policy. The exclusion of CSP directives on your OSLC solutions is a path.

Option 2 is slightly more complicated but will have stronger approval from your IT Security team. We recommend you use both frame-src and frame-ancestors to provide a robust limit of external interaction and smooth collaboration of your OSLC tools.

In OSLC, we describe the set of Friends as the ones that we want to embed their content. This we can align to a frame-src directive.

frame-src https://myfriend1.com https://myfriend2.com:9443 'self';

In OSLC, we describe the set of Consumers as the ones that we are allowing to use our content. This we can align to a frame-ancestors directive.

frame-ancestors https://myconsumer1.com https://myconsumer2.com:9443 'self';

It is often the case that the Friends and Consumer list is the same because we usually do OSLC bi-directionally. However, there are some cases where a reporting tool may only be a consumer, so we should keep this consumer/friend distinction in mind.

For each of these directives, the technology solution you implement will vary. We recommend reviewing the details both with the IT Security team and the Administrator of your web application or proxy. These suggested values only enable the required OSLC interaction of a particular application. If there are additional rules or exceptions, it is up to your security team to incorporate these rules.