Learning: eZ Publish Security

This is a Stub article. Help the eZ Publish community by expanding it!

For a general description of security, we recommend Computer security on Wikipedia.

eZ publish is very secure! The U.S Department of Defense uses eZ publish!

Securing eZ publish

eZ Publish Security Advisories

eZ Publish Security Advisories ( http://share.ez.no/community-project/security-advisories ) - keeping your eZ Publish installation up-to-date with the latest release and security patches is a good way to ensure the underlying code base is stable & secure.

File Permissions

"Also in productive environments the extension directory should not be any longer writeable to apache cause of security." -- tos@ez.no

  1. Installation directory permission
  2. File storage settings in site.ini.append.php , for cache/image files within the var directory:

Web server user/group should only be on var/, unless making template/ini changes via admin interface.

Database Permissions

  1. Use a separate user for each eZ publish installation
  2. Reduce user database server permissions to minimum.

Module view security

There are several module views are available to anonymous users by default which can expose information about your software and website:

  •  ezinfo/about contains the version of eZ Publish, and all extensions used by your website, as well as information about copyright, license, contributors, etc.
  • content/browse can allow a user to explore the node structure of your site, to access information which is not linked on your site.
  • user/register, user/activate, user/success, and user/forgotpassword can also be disabled if you don't need user registration on the front-end, to prevent spammers clogging up your system, or people accidentally using it

There are several ways to disable these module views for anonymous users - both are by changing settings in site.ini:

  1. Remove if from [RoleSettings] PolicyOmitList (require policy access)
  2. Add it to [SiteAccessRules] Rules disable list (disable it totally)


You can reset the site.ini:[RoleSettings] PolicyOmitList array with a settings override to exclude the module entirely thus preventing it's use and index from other external sources (engines, bots, etc)

Here is an example from a settings/override/site.ini.append.php file:

# PolicyOmitList[]=ezinfo

You might choose for example to leave this enabled in development settings while disabled directly in production settings.

You could also add a new user group and coresponding new role for that group called say 'Developers' and within the role add a policy for ezinfo module and the read function. Save and clear caches. Now all developer group users can use ezinfo and everyone else gets access denied errors instead.


If you want to completely disable a module view so no-one can use it, you can reset the site.ini:[SiteAccessRules] Rules array with a settings override, e.g:


HTTP Headers

eZ Publish adds an HTTP header "X-Powered-By: eZ Publish" - you can override this.

In eZ Publish 4.7 you can change a setting in config.php:

 /*** Enable usage of "X-Powered-By" headers.
* Optional. Defaults to true.
define( 'CLUSTER_HEADER_X_POWERED_BY', false );

In eZ Publish 4.6 & below, in your settings/override/site.ini.append.php file by adding the following (and while we're at it, let's turn off the webserver identifier):

# Enable/disable custom HTTP header data.
# Only apply custom headers for anonymous users 
# Header list. Contains all HTTP which should override standard ones.

eZ publish Administration

Browser security

  1. Use an browser and web server which supports ssl/https. Require all login and admin usage use ssl.
  2. The use of ssl protects the clear text information (username and password) during transmission.
  1. Use an httpd browser based authentication realm to protect eZ publish
  2. The use of two forms of authentication, ACL and eZ reduces greatly the chance someone can compromise eZ publish

eZ publish Users, Groups, Roles and Permissions

  1. Do not use the 'admin' user. This is similar to the unix-like operating system's rule to use a non-privileged user as much as possible.
  2. If you need more permissions, create a group called say 'ez-admin', and add a new user 'eza-john' to the group. Add permissions as needed to your group/user roles.

Security related topics

External resources