Minimum security requirements for Kentico CMS

We are quite often asked on the minimum security requirements for Kentico CMS to be able to run. It is quite hard to cover that because it depends on what particular things you need to do, read more if you want to learn the details ...
Hi everybody,

Defining precise security requirements for a general web application is hard, since it depends on particular needs of a client. That is basically why we recommend following settings for everybody:
  • Database access with modify permissions to both data and database structure - Since during the development phase, the client needs not only access and write the data, but also define new database tables.
  • File system access with modify permissions to the root of the web site - Again, the development may bring different tasks, with different needs to write to the file system based on configuration, so we cannot say exactly where it will be for everybody.
What we can do is to point you to the right direction if you want to somehow limit your web site account within the web site.

Database permissions

I start with database permissions since this is pretty easy to discuss, there are basically only two types of permissions needed:

The database account must be able to modify the database structure, in case you need to perform one of the following (you need to ask yourselves what you will need to do):
  • Add or modify the structure of Document type, System table, Custom table or BizForm
  • Import any package with our Export/Import tool from Site manager (since it may cause some of the previous actions)
  • Use object staging for any of the previously listed objects (for the same reason)
  • Apply the Upgrade procedure to newer version of Kentico CMS
  • Call any API causing previously listed things, such as Table manager and related providers
So you can see that unless you are doing development tasks, you don't need this access for live site. But you will need to use some account with more permissions if you want to perform any of those tasks above.

The database account must be also able to read and modify the data for obvious reasons, the content and objects are stored in the database, so it must allow the application to do that. No doubts about it. If you could ensure that the application will never need to write to the database, you could avoid the modify part, but as long as somebody comes there and attempts to save anything (including login), the application needs to write there.

That is pretty much all about database permissions. I can only recommend to not allow modification for the production site if that is really important for you, nothing more.

File system access

With file system access, it is more complicated, since different parts of the system need to access different paths in the application.

In general, you need to grant some file system write permissions to the account under which the application runs, by default it is:
  • On Windows XP - ASPNET
  • On Windows Server - NETWORK SERVICE
  • On Vista - NT Authority\System machine
Of course if you use different account for your application pool (IIS process), you need to use that account.

The most difficult part of this are the permissions required for the Export/Import functionality, since it may need to write to different locations, see following list of folders:

And note, that the Export/Import may need to write to the green, blue and black folders listed above.

For the runtime, different modules typically need to write to App_Data folder, so you need to grant them the modify access to this folder:
  • Web analytics
  • Smart search
  • Import/Export (also new site wizard)
If you want to use any of those, grant the modify access to App_Data folder.

Attachments, Documents and Media files

The files in general require modify permissions if they are set in the settings to be stored in file system or if they are media files (these are always stored in file system)

The files are basically divided into two groups, one are the Global files, which are files like Avatars,
Attachments of global objects, Teaser images of global objects, etc. These are stored in folder CMSFiles unless the folder is configured differently in settings.

The other files are Site files, which include Document attachments, Attachments or teasers of site-related objects, and Media files. Such files are stored in the folder with the same name as the site code name, unless configured differently.

In case you define different file path in the settings, you need to grant that new folder with modify permissions.


Deployment (precompilation) of the web site project may need additional modify permissions since it needs to write the virtual objects to the file system from Site manager. The folders it needs to access are following:
  • CMSTransformations - All transformations
  • CMSPageLayouts - Template layouts
  • CMSLayouts - The shared layouts
  • CMSWebPartLayouts - Custom web part layouts
And that is pretty much it.

Summary of files permissions

Here is the summary for the file permissions

Folder When modify permission for files may be needed
App_Code Import 
App_Data Export/Import
Smart search
Web analytics
App_Themes Import
CMSFiles Import
Global files stored in file system 
CMSFormControls Import
CMSGlobalFiles Import
CMSInlineControls Import
CMSModules Import 
CMSSiteUtils Export 
CMSTemplates Import 
CMSWebParts Import
<site code name> Import
Site files stored in file system
Media library
CMSLayouts Deployment 
CMSPageLayouts Deployment
CMSTransformations Deployment
CMSWebPartLayouts  Deployment 

Hope I didn't forget anything.


I promised you it won't be so simple as you can see now, I think it is much better to just grant the root the modify permissions and SQL account the DB owner permissions, and do not care about all these things in most cases.

In case you really insist on setting permissions to only appropriate parts, make your own list of requirements and choose what you need based on this article.

Just note: We cannot guarantee you that this list is final, since new features may require additional permissions and I also cannot guarantee that it is complete, if you find out that anything is missing, let me know in the comments, I will update it.

See you next time ...
Share this article on   LinkedIn

Martin Hejtmanek

Hi, I am the CTO of Kentico and I will be constantly providing you the information about current development process and other interesting technical things you might want to know about Kentico.