:: Version 3.1.0 ::

Security best practice

iTop is based on PHP and its content is served by web-server.

This page reference PHP and web-server configuration that will enhance the security of your iTop installation.

Directories write permissions

The web server user should be allowed the write permission on the following directories, under the iTop root :

  • conf
  • data
  • env-*
  • root directory (iTop Hub connector will remove the env-production-build directory before compiling)
  • log
Write permission on the conf folder is only needed during the initial setup and for editing the configuration file interactively inside the application.

Secure critical directories access

The iTop packages contains configuration files for both Apache HTTPD and Microsoft IIS, see the corresponding pages

Here are file directories that must be denied to the web users :

  • conf : directory and all of its content
  • data : directory and all of its content
  • datamodels : allow only files having one of those extensions : css|scss|js|map|png|bmp|gif|jpe?g|svg|tiff|woff2?|ttf|eot|html
  • env-* : allow only files having one of those extensions : css|scss|js|map|png|bmp|gif|jpe?g|svg|tiff|woff2?|ttf|eot|html
  • extensions : allow only files having one of those extensions : css|scss|js|map|png|bmp|gif|jpe?g|svg|tiff|woff2?|ttf|eot|html
  • lib : directory and all of its content
  • log : directory and all of its content
  • setup/permissions-test-folder/permissions-test-subfolder/ : only required if your webserver doesn't use .htaccess or web.config. If access not denied, you will have a Security Warning during iTop setup (since 3.0.2 and 2.7.8)

You should also prevent directory listing.

Use https

You should serve your pages only using the https protocol.

As stated by wikipedia: it protects against man-in-the-middle attacks. The bidirectional encryption of communications between a client and server protects against eavesdropping and tampering of the communication.

Prevent session theft

While PHP default configuration is quite relevant from a security point of view, it can be enhanced: you should change the default value for those entries:


In order to prevent malicious javascript code to sniff the user's session, you should enable session.cookie_httponly (see php documentation)

you can do so either in your php.ini using session.cookie_httponly = 1, or within apache with php_flag session.cookie_httponly on.


If you use https, you should enable this directive so cookies are only sent over secure connections, see php documentation.


You should enable this directive with LAX value so that session cookie would be harder to intercept, see php documentation.


This PHP parameter which can be set to false by default in some PHP distribution, should be set to true to avoid that in case of exception the arguments values are written in clear text in the error_log. This arguments can contain login and password to the iTop Database for eg.

Additional http headers

While not as critical as the previous configuration, you can configure those http headers within your web server in order to add extra layer of security. Since this page try to remain simple, the headers mentioned here can often be fine tuned to be even more restrictive.

The examples below are for apache and require the mod header, but all mainstream webserver provide a way to configure them.


Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;" env=HTTPS

This tell browsers that it should only be accessed using HTTPS, instead of using HTTP. more informations


Header always set X-Frame-Options "sameorigin"

This indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. MDN documentation.

Since iTop 2.7.2, the X-Frame-Option is set for almost every pages served by iTop (header is set in the WebPage class).
In 2.7.2 it was set to 'denied', and beginning with 2.7.3 it is set using the security_header_xframe config parameter (default to SAMEORIGIN).
See this GitHub advisory : Admin pages are cached and can be embedded


Header always set X-Content-Type-Options "nosniff"

This allows to opt-out of MIME type sniffing (the MIME types advertised in the Content-Type headers should not be changed), MDN documentation.


This helps to detect and mitigate Cross Site Scripting (XSS) and data injection attacks.

Beware: this header will block any not authorized domain, this make it is more difficult to properly configure. The MDN has an excellent article: Content Security Policy (CSP), you should refer to it in order to perform a proper configuration.

A basic configuration may be

Header set Content-Security-Policy "default-src 'self' www.itophub.io;script-src 'self' www.itophub.io 'unsafe-inline' 'unsafe-eval' blob:; style-src 'self' 'unsafe-inline';img-src  'self' data: blob: www.itophub.io "

But, for example if you make use of recaptcha or other, you will have to allow also “www.google.com” and “www.gstatic.com”:

Header set Content-Security-Policy "default-src 'self' www.itophub.io;script-src 'self' www.google.com www.gstatic.com www.itophub.io 'unsafe-inline' 'unsafe-eval' blob:; style-src 'self' 'unsafe-inline';img-src  'self' data: blob: www.itophub.io "

Regarding the difficulty to maintain a correct configuration, we do not include this header in the example below, but if you feel confortable with extra maintenance, you can add it.

Complete example

php_flag session.cookie_httponly on
Header always set X-Frame-Options "sameorigin"
Header always set X-Content-Type-Options "nosniff"
# only for https:
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;" 
php_flag session.cookie_secure on
3_1_0/install/security.txt · Last modified: 2023/07/21 10:19 (external edit)
Back to top
Contact us