Kentico CMS Security White Paper

We at Kentico recognize web security as crucial aspect of our system. As we want to prepare and provide a highly secure web content management system, we prepared a document for developers, which describes writing of secure code.

The security white paper intends to describe the most common security vulnerabilities we have to face in the Internet environment. You will learn how to identify them and how to secure your website against them.

The paper is focused on security of Kentico CMS. But, if you are not familiar with this web content management system, you can still use it to understand website security in general and to improve security of your websites.

You will learn how to protect your websites against the following attacks:

  • XSS (cross site scripting)
  • SQL Injection
  • Argument Injection
  • Code Injection
  • XPath Injection
  • CSRF/XSRF (cross site request forgery)
  • Session Attacks
  • Directory Traversal
  • Unvalidated Redirects and Forwards
  • DoS (Denial of Service)


The security white paper is available for the download at

Share this article on   LinkedIn Google+


Dominik Pinter commented on

Hi Keith,
thank you for your feedback! I (as a author of document) personally really appreciate it.

<pages validaterequest="true" /> - I totally agree with you, it could solve lot of problems. On the other hand it takes away some of your options. For example Kentico CMS uses WYSIWYG editor on many pages and this editor sends html code to server when you press Save - you couldn't use WYSIWYG editor with validaterequest="true". That is why request validation is disabled by default. But if you don't need features like this you can enable request validation. Another option you have is to enable request validation on single pages. For example, if you are creating web sites using ASPX templates you can enable request validation on every page.

Disallowing all script and HTML entry ... - I'm not sure what you have in mind by this sentence, do you think we should offer some similar solution to yours (create application firewall/IDS for rejecting evil input)? In that case you can post your suggestion to our uservoice and we will definitively consider it.

Yes, it doesn't cover everything, we tried to focus on most common issues/situations. Do you miss some certain information? We can cover that topic in documentation, by blog post or in second edition of security white paper.

Keith patton commented on

<pages vakidaterequest="true" /> would solve a lot of problems, but kentico forces this setting to be false requiring developers to manually handle every single piece of data in and out, very error prone and risky.

We are working on an http handler that will allow us to reject HTML and script input for non cmsdesk/cmssitemanager activity via a configuration setting.

Disallowing all script and HTML entry is a recommended security best practice and something I believe kentico should work towards enabling as an option.

It doesn't cover everything, but it's a great start.