Restrict Delivery API access using API key — give us feedback

TomasHrubyTomasHruby Member, Kentico Staff mod
edited February 6 in Back-end Development

Good news for those of you, who hijack the Preview API to provide private content or who turn down deals because of the Delivery API being public-only. We are up to introducing security mechanism that allows you to secure your inventory and provide paid or member-only content. So, let me validate our design with you using this article.

In short, we plan to add the possibility to enable a Delivery API key. As a result, all Delivery API requests are going to need to bear an API key, similarly to the case of the Preview API. However, this enabling Delivery API key will have the following impact on your website's architecture:

  • Server-rendered apps (e.g. .NET MVC) — Your server app will communicate with Kentico Cloud using the API key. Since you will not share the API key, no one else will have access to your Delivery API. If your project requires managing app users and roles, you will need to implement it individually because Delivery API contains only a single API key without the native ability to handle roles.
  • Client-rendered apps (e.g. React) — Your React app will communicate with a proxy service developed by you. It might be a small node.js server that proxies all website requests and securely communicates with the Cloud's Delivery API.

> Note that the Delivery API security will be opt-in. Therefore, it can't break your current app and you can decide if and when you want to introduce security.

To summarize, all Delivery API requests will need to go through a server proxy. So, there is one important performance impact for the client-rendered apps. In order not to leak Delivery API key, even public content such as homepage will need to go through a proxy, without getting the content from our high-performance CDN. In practice, if you needed to get secured content with the global availability and speed of our CDN, you might end up integrating with your own CDN.

Potentially, we might implement a functionality which allows you to define that specific section of content inventory such as items of specific content types or items assigned to specific sitemap locations should remain accessible without the API key (publicly).

  • What content should remain public? Why?

Last but not least, assets need to be secured as well. However, an asset URL contains it is ID. Since there's no asset listing endpoint, the asset ID can't be guessed so quickly. Therefore, as long as the asset is a part of member-only content items, it remains private.

Let us know your opinion on the new secured Delivery API idea. Honest feedback is more than welcomed. Feel free to comment here or reach out to me at

Stay tuned for other Kentico Cloud improvements!



  • LeeConlinLeeConlin Member ✭✭

    I have a couple of issues with this...

    1. A change of this nature forces existing applications to be redeveloped to implement either the API key or a proxy - this is unacceptable for a service that is hosting live sites. I agree that we need the option of securing the delivery API but this change should not break existing sites.
    2. Why is it all or nothing?

    My suggestions

    1. Make a new field type that can be applied to content types - Security. This type would function in a similar way to how taxonomies do currently such that you can make multiple selections, but with the caveat that you can only have one per content type, similar to how the UrlSlug type works currently.
    2. In the API Keys module provide a section where I can get a separate API key for each selection on the Security taxonomy.


    I have a "Security" taxonomy (for lack of a better term) with the following possible values:

    • Standard Member
    • Premium Member
    • VIP Member

    In the API module, these three should appear, each with their own unique API key.

    On my content types that I wish to apply security to I add a "Security" element.

    On the Content Items of those types, I would now have a checkbox list to select zero or more of the three items listed above. If I select more than one value then any of the appropriate API Keys will suffice.

    If I select zero items in the security element then the content item is "unsecured" and does not require an API key. Likewise, if the security element doesn't exist on a content type, any content items of that type would not require an API key.

    This serves to allow existing sites to continue without requiring modification while providing a method to secure pages for both new and existing sites that can be implemented if required.

    This also means that for public content types the KC CDN/API can be used directly in JavaScript apps and that a proxy would only be required for the secure areas of a site.

    The same element could be applied to content items and, if an asset should be secured, then it should only be available via an API call with API Key (or as part of content items retrieved by such a call)

  • TomasHrubyTomasHruby Member, Kentico Staff mod
    edited August 2017

    After reading the first concern I realized that I didn't state it explicitly that the new Delivery API security will be optional. Actually, it's going to be opt-in. So, there won't be any breaking changes (and we will never release anything that could break your app). Thanks, @LeeConlin for helping me, I've updated the article.

    As for the second part, we need to find a compromise between managing visitor roles in KC and managing these roles in a separate environment. I admit that we could implement more sophisticated users and roles mechanism, e.g. by introducing an authorization service or allowing to create more API keys with different scope (e.g. by type, by taxonomy, or, as you suggest by content item).

    Naturally, even with one Delivery API key, you can create and store 3 new tokens, ensure that after logging in, every visitor role gets a correct token. Then, when calling the Delivery API, you can filter content by taxonomy (Standard, Premium, VIP) and include a global Delivery API key. I understand this approach requires additional coding. However, I'm curious how much.

    • How would you estimate the effort to create such authorization proxy?
    • Would it be a show-stopper for your projects regarding using secured content?
    • Are there another reasons that would degrade your experience with KC or impact you or the project in a negative way?
  • LeeConlinLeeConlin Member ✭✭

    Adding another layer to proxy requests and responses will be a performance issue for SPAs as they will either no longer be able to leverage the speed of your CDNs or they will need to purchase additional server power to match them.

    In either case, a proxied app will never be as fast as un proxied simply due to the man in the middle.

    Also, many SPAs would be hosted as simple static HTML/CSS/JS sites requiring zero backend code since all of the content would currently come from your API. Setting up a proxy would potentially mean paying for additional hosting in these cases which should be unnecessary when already paying for the static hosting plus Kentico Cloud.

    I'm at a loss for an idea as to how you might overcome this issue without providing a site membership system from your end and then implementing site member roles, etc.

  • TomasHrubyTomasHruby Member, Kentico Staff mod

    Thanks, @LeeConlin . I agree with you. The ability to proxy the private content will be a good first step for Kentico Cloud users. Nevertheless, in the future, we will definitely need to improve both performance and unnecessary infrastructure for SPAa.

  • LeeConlinLeeConlin Member ✭✭

    Another thought on this... once it's been turned on it should be possible to set REST queries that determine which content should not be secured. That way you can write one or more DeliveryAPI queries that open up some of your content.

  • TomasHrubyTomasHruby Member, Kentico Staff mod

    It will be up to you whether you keep all content public (current state) or protect it using API key. So, if I understand it correctly after you enable the Delivery API key, you want to be able to write Delivery API queries which can omit be API key? What kind of queries would you add? With type filter, taxonomy filter or other?

  • I'm happy with this as a solution that will cover the primary security concern I have over using KC with our clients.

    It doesn't help when using JavaScript to directly access the API, but it is a good first step. Regarding Javascript, the proxy isn't a bad solution, especially if you implement caching, but it does mean extra development time/hosting costs.

Sign In or Register to comment.