Note: This guide describes Kentico CMS version 7. Unfortunately, we cannot support this guide from version 8 forward. Go to latest documentation

Skip to end of metadata
Go to start of metadata

The purpose of special permissions in Kentico CMS is to prevent the privilege elevation attack. In this type of attack, a lower privilege user can gain access to functions only available for higher privilege user. For example, CMS editors with permissions to edit content are able to elevate themselves to the global administrator level.

The special permissions cover three different areas:

Only the global administrator can configure these settings.

Content editors and other users cannot grant or remove these special permissions. Even if you assign users to a role which is allowed to modify permissions, these special permissions will be disabled, which is indicated by a yellow shield icon:


On this page

ASCX code in layouts

The Edit ASCX code permission for the Design module allows users to edit ASPX/ASCX code of page layouts and transformations.

When you grant the Edit ASCX code permission to a certain role, then a user in that role can edit such code in layouts and transformations and can run any code in them – for example, the code that elevates privileges. Without the permission, the user cannot do this.

SQL code in web part properties

The Edit SQL code permission for the Design module allows users to edit SQL WHERE and ORDER BY properties in various web parts (e.g. the query repeater).


If you grant this permission to a role, a user in that role can write any SQL statement into WHERE and ORDER BY. Without it, the user can only write simple WHERE conditions like “UserID = 1” and ORDER BY statements like “UserID”.

SQL code in reports

In the Reporting module you can write any SQL statement in order to get data from the database into a chart. This could also be dangerous because a user can elevate privileges or get sensitive data from the database using the SQL code.

The Edit SQL Queries permission indicates whether the given role can edit SQL queries in reports.

Alternatively, you can change the connection string for reports. With that, you can create a special user account on the database level with limited permissions. For example, the database user will not be able to execute any UPDATE/INSERT/DELETE queries.

Another approach could be to separate the data into multiple databases. The first database would contain only reporting data, and the second database all other data including users. Then, the reporting module would be able to work only with the reporting data (and the user would not be able to execute malicious queries). Of course, in this scenario, you have to somehow deal with data synchronization.

Configuring multiple connection strings

  1. Open web.config file and specify a new connection string in the <connectionStrings> section. The name attribute must be unique. 
  2. Go to SiteManager -> Settings -> Security & Membership.
  3. Select the new connection string as the Default report connection string in Reporting category. 

  4. Set the Set connection string permission of the Reporting module. 
    • Only a user in a granted role or the global administrator can change the connection string of a report. 

Allowing code editing for site administrators

In Site Manager -> Settings -> Security & Membership, notice the Enable code editing for site administrators option in the Administration section. Here, you can specify whether site administrators (global administrators without access to Site Manager) can edit ASCX, Reporting SQL queries and WHERE and ORDER BY in web parts.


From a security standpoint, best practice is NOT to grant any of the permissions listed above to any roles. You should also not allow site administrators to edit code. If you do not follow this recommendation, you risk elevation of privileges.