Managing Content Security in Telerik ASP.NET Core Applications

The new Telerik UI for ASP.NET Core project template gives you better protection—it’s how to make CSP work for you.

Let’s say, for example, that you’ve been happily building ASP.NET Core applications using the Progress Telerik Visual Studio extensions to generate the start point for your projects. All is going well until you start to build a new application, confident that you know what you’re doing and how all of this stuff works … except, this time, when you start your application, it doesn’t actually work.

If the symptoms are that images aren’t displayed or stylesheets aren’t applied or video doesn’t play, or web service requests aren’t issued, then the problem may be a Content Security Policy (CSP).

To confirm if the problem is CSP, just press F12 in your browser, check the messages in the console window and see if you find a message like this one (the asterisks represent message content that will vary, depending on the problem):

Refused to load the https:// because it violates the following Content Security Policy directive.

If you’re using the default Telerik template as a starting point for your project, the culprit is a <meta> tag that’s automatically included in the project’s Layout.cshtml file (the file is the default base for all your views). Here’s the current version of that tag, formatted to make it easier to read:

<meta http-equiv="Content-Security-Policy"
  content="default-src 'self';
  
    img-src 'self'
      data:;

    script-src 'self'
      https://kendo.cdn.telerik.com
      https://code.jquery.com/
      https://cdn.kendostatic.com
      https://unpkg.com
      https://cdn.jsdelivr.net 'nonce-Telerik-Examples';
 
    style-src 'self'
      https://kendo.cdn.telerik.com
      https://unpkg.com
      https://cdn.jsdelivr.net;

    font-src 'self'  
      https://unpkg.com;

    connect-src 'self'
      ws:
      http:;" />

You could make your error go away by just deleting the tag, but that’s probably a mistake. This Content Security Policy (CSP) <meta> tag helps protect against code injection and cross-site-scripting (XSS) attacks.

Fundamentally, this CSP helps protect your project by limiting the sources where your page can retrieve scripts, stylesheets and images (or any other resource) to the sources listed in the <meta> tag.

However, it also means that if you’re downloading resources from something that Progress Telerik can’t consider (your organization’s stylesheet site, for example), well, then your application won’t work.

To fix it, you first need to know how to read the CSP added in the <meta> tag.

Reading the Default <meta> Tag

A CSP like the one added in the <meta> tag is divided into multiple sections (called directives), separated by semicolons. A directive begins with the directive name and is followed by series of space-delimited sources.

The key directive is default-src which, unless overridden in other directives, specifies where the page can download resources from (in CSP, default-src is considered the fallback when other directives aren’t provided). Here’s the default-src directive from the <meta> tag, listing one source—the keyword 'self':

default-src 'self';

The 'self' keyword limits downloads to resources from the same domain that your page was downloaded from. The other directives override that default list for specific types of content to add additional sources.

The img-src directive, for example, lets you specify sites that you want to enable for downloading images. The <meta> tag in your Telerik-generated project uses 'self' to download images from the same domain as the page but also adds any image using a URI that begins with data. (The data: URI lets you embed base64 encoded files directly into your page rather than having to download them separately.)

img-src 'self'
  data:;

The other directives specify sources for:

• Downloading JavaScript files: Your page’s domain, the Telerik site, plus some public and content delivery network sites like unpkg.com (script-src). The nonce keyword causes the server to generate a one-time random key that is included in the download and checked by the browser to verify that the script is coming from the requested server:

script-src 'self'
  https://kendo.cdn.telerik.com
  …
  https://cdn.jsdelivr.net 'nonce-Telerik-Examples';

• Downloading stylesheets: Same kind of sites as with script files (style-src)
• Downloading fonts: Both your page’s domain and unpkg.com (font-src)
• Calling WebSockets and web services: Requests to your page’s domain plus all WebSocket requests and HTTP/HTTPS requests (connect-src)

The result of this CPS is that every source not in those lists is blocked—that includes stylesheets, images, audio/video files and so on that aren’t coming from your application’s domain. Getting your application running, then, comes down to extending those lists to include those other sources.

Side note: When reading or modifying a CSP, allowing HTTP also allows HTTPS (and vice versa). An img-src directive that includes http:phvis.com, for example, would still allow this image tag to download its image over HTTPS:

<img src=https://phvis.com/SomePictureOnPetersSite.jpg />

Tailoring the Telerik <meta> Tag

Typically, you’ll run into a CSP problem because you’re accessing a resource from somewhere other than your page’s domain (for example, some shared image/stylesheet site or a video from a streaming site). When you do run into this problem, you have two ways of fixing it:

• Extend the default-src directive to include the other site. This makes sense if you’re downloading multiple resources from that site and have confidence in its security (a central corporate site with resources to be used on all of your organization’s pages).
• Extend the directive for the specific resource that’s being blocked (e.g., adding the URL where your organization’s stylesheets/images are kept).

That last option may include adding a new directive if the resource isn’t one of the types already listed in the CSP (e.g., if the blocked resource is a video or audio file on another site). For a video or audio file, for example, you need to add the media-src directive to the CSP (see the directives list for other types of resources).

On the other hand, if your organization requires something more restrictive (the “Block All, Allow Some” strategy) or you’d prefer something more flexible (the “Allow All, Control Some” strategy), you may want to swap in a different CSP altogether.

Defining a Content Security Policy

If you want to go beyond setting CSP pages for individual pages, you can configure your web server to return a CSP as one of the response headers for any request. If you do, you’ll also have more options than are available using the <meta> tag. I’ll continue with the <meta> tag, however.

The starting point for your CSP is a policy that has no content: A policy that specifies nothing allows everything. Continuing to use the <meta> tag as my example, a policy that allows everything would look like this:

<meta http-equiv="Content-Security-Policy" />

Or, more explicitly:

<meta http-equiv="Content-Security-Policy" />
  content="" />

Building from that, you can implement one of three strategies: “Allow All, Control Some,” “Block All, Allow Some” or “Allow Some, Control Some.”

Allow All, Control Some

Implementing an “Allow All” strategy begins with omitting the default-src directive which provides the fallback for any omitted directive. Without a default-src, any directive you don’t provide allows everything.

Starting from there, you control just the resources you’re interested in by including directives for those resources. This example only blocks scripts (they must come from the page’s domain or my site) while allowing every other kind of resource:

<meta http-equiv="Content-Security-Policy"
  content="script-src 'self'
    http://phvis.com" />

This strategy makes sense when you feel there are only a small number of resources you need to control. This is the riskiest strategy (have you controlled all the right resources?) but will have the least impact on your applications.

Block All, Allow Some

Another strategy is to block everything and then allow specific resources. With this strategy, your starting point is to provide a CSP with a default-src with no value—that will block all resources:

<meta http-equiv="Content-Security-Policy"
  content="default-src;" />

If you want to be more explicit, you can use 'none' to make it clear that you’re blocking everything:

<meta http-equiv="Content-Security-Policy"
  content="default-src 'none';" />

You can now selectively allow some resources to be downloaded. This example lets in images from the page’s domain and my site but still blocks stylesheets, WebSocket access, web service requests and everything else not mentioned in this CSP:

<meta http-equiv="Content-Security-Policy"
  content="default-src 'none';"
  img-src  'self'
    http://phvis.com" />

This is probably the safest strategy but will have the biggest impact on your applications (to be more exact: more applications will stop working). It will also lead to the longest CSP list and maintenance effort as you’ll keep having to add more directives as your sites access a wider variety of resources from a longer list of sources.

Allow Some, Control Some

The third strategy is to use default-src to specify any common source for all the resources you will allow (typically that’s just 'self'—your page’s domain). You then add directives for specific resources that require something more. This is the strategy that Telerik has used in its CSP.

As you add those other directives, remember that those new directives don’t extend default-src but, instead, override it. Essentially, that means that most/all of your additional directives will begin with whatever you have in the default-src directive.

This example allows any resource from my page’s domain and my site to be downloaded, except for images. For images, this policy allows images from the page’s domain, my site and the Telerik site:

<meta http-equiv="Content-Security-Policy"
  content="default-src 'self'
    http://phvis.com;

    img-src 'self'
      http://phvis.com
      http://Telerik.com" />

This strategy is, essentially, a trade-off between the other two: By providing a fallback in default-src that allows resources from your “safe” sites, it reduces the number of directives that you’ll have to add. You’ll now only need to add directives where you need to specify a different or longer set of resources than your default list of “safe” sites.

So: Yes, CSP can be annoying. But CSP helps protect you from being attacked. And, considering the embarrassment that comes from finding your site defaced or hacked, it’s probably worth implementing the strategy that saves you from explaining how that happened.

Learn more about Progress Telerik UI for ASP.NET Core and try it yourself, free for 30 days.