How to Harden PHP Settings for a Website in ISPConfig

This guide shows you how to tighten the PHP configuration of a single website in the ISPConfig control panel on your Noiz hosting account. It is aimed at self-managed server administrators, and at resellers whose accounts have been granted the website option tab, because both of the fields involved sit on a tab that client-level logins do not see. You will learn how to pick a PHP execution mode that supports per-site overrides, how to limit which directories PHP may touch using the PHP open_basedir field, and how to switch off risky PHP functions and apply other protective directives through the Custom php.ini settings field on a website's Options tab. Throughout, "hardening" simply means reducing the number of things an attacker or a compromised script can do. The examples are written for current PHP 8.x, not the older PHP 5 and PHP 7 defaults you may find in older tutorials.

Last reviewed: 27 July 2026, against ISPConfig 3.3.1p1. This guide is written for Noiz hosting and is kept current against ISPConfig. It complements, and does not replace, the official ISPConfig documentation linked below. ISPConfig evolves between releases, so if a screen differs from this guide, check those links.

Official Documentation Reference

• ISPConfig 3 User Manual: the official manual; the website Options tab, the PHP open_basedir field and the Custom php.ini settings field are described in section 4.6.1.1 (Website), and PHP execution modes are compared in the same chapter.
• PHP manual: disable_functions: the official reference for the directive used to switch off individual PHP functions. It confirms this setting is INI_SYSTEM only, meaning it must be applied in the PHP configuration and cannot be re-enabled by a script or an .htaccess file.
• PHP manual: open_basedir: the official reference for confining PHP file access to a set of directories.
• PHP manual: where a configuration setting may be set: explains the directive classes (INI_USER, INI_PERDIR, INI_SYSTEM, INI_ALL) that decide whether a setting can be changed per site at all.
• PHP supported versions: the official list of PHP releases that still receive security fixes, so you can choose a version that is not end-of-life.

Prerequisites

• You know how to log in to the ISPConfig control panel.
• You sign in as the ISPConfig administrator, or as a reseller whose account has the website option tab enabled. Both hardening fields live on the website's Options tab, and that tab is not shown to client-level logins.
• You already have a website in ISPConfig. If not, see how to create a website in ISPConfig first.
• You understand basic php.ini syntax, which is one directive = value per line, with ; starting a comment.
• You have a way to test the site after each change, ideally a staging copy or a quiet maintenance window, because an over-strict setting can take a live site offline until you undo it.
• Server-wide changes, adding PHP versions and per-account permissions require administrator access. If you are a managed Noiz client, those are handled by the Noiz support team on request.

How PHP settings reach your site in ISPConfig

Two facts decide whether a hardening directive will actually work, so it helps to understand them before you start.

• The PHP mode controls whether per-site overrides are possible at all. ISPConfig can run PHP in several modes. Only some of them let you feed custom php.ini values to one website. In particular, the Custom php.ini settings field works with Fast-CGI, CGI, SuPHP and PHP-FPM, but it does not work with Mod-PHP. If a site runs under Mod-PHP, you cannot harden it with this field until you switch its mode.
• Some directives can only be set at PHP startup. The most important hardening directive, disable_functions, is in the INI_SYSTEM class. According to the PHP manual it must live in the PHP configuration itself and cannot be set in an .htaccess file or turned back on by a running script. That restriction is exactly what makes it useful for security: once applied, a compromised plugin cannot lift it. ISPConfig writes the value into the site's own php.ini for Fast-CGI, or into the site's PHP-FPM pool as a php_admin_value for PHP-FPM, both of which honour INI_SYSTEM directives.

Step 1: Choose a secure PHP mode

Open the website and find the PHP setting

1. In the ISPConfig panel, go to Sites.
2. Under Websites, click the domain you want to harden, for example yourdomain.com (an example value).
3. On the Domain tab, find the PHP drop-down.

Which mode to choose

On a modern Noiz platform the two practical choices are PHP-FPM and Fast-CGI. Older modes still appear for compatibility but are not suitable for hardening a website:

• PHP-FPM (recommended). Scripts run as the website's own Linux user rather than as the web server, more than one PHP version can be offered, and per-site overrides work through the Custom php.ini settings field. This is the best default for almost every site.
• Fast-CGI. Also supports the Custom php.ini settings field, writing your values into a php.ini that belongs to the site. A reasonable alternative on Apache.
• Mod-PHP. Avoid it for hardening. Scripts run with the web server's privileges, which weakens isolation, only one PHP version is possible, and the Custom php.ini settings field cannot be used at all. On a site that must stay on Mod-PHP the same values can only be applied through the Apache Directives field on the Options tab, using php_admin_value and php_admin_flag. Changing the mode to PHP-FPM is the better fix.
• CGI, SuPHP and HHVM. Legacy modes that still appear in the drop-down. CGI and SuPHP do accept custom php.ini settings but offer no advantage over PHP-FPM, and SuPHP is no longer maintained upstream. HHVM does not support every PHP function. There is no reason to choose any of them for a new configuration.

Select PHP-FPM (or Fast-CGI) and, on the same Domain tab, confirm the SuEXEC checkbox is ticked. That checkbox is an Apache-only option, so it will not be present on an nginx server. SuEXEC is what makes Fast-CGI and CGI scripts execute as the website's own user and group rather than as the web server, and the official guidance is to activate it for PHP-FPM, Fast-CGI and CGI alike. Leave the site open, because the version selector appears next.

Choose a supported PHP version

When the mode is PHP-FPM or Fast-CGI, a PHP Version selector appears. Running an end-of-life PHP release is itself a security weakness, because it no longer receives fixes, so pick a version that is still supported.

1. Open the PHP Version drop-down.
2. Select a currently supported PHP 8.x release. Check the PHP supported versions page if you are unsure which releases still receive security updates.
3. Confirm your application supports that version before switching a live site, as a major version jump can require code or plugin updates.

If the version you need is not listed, a server administrator adds it under System > Additional PHP Versions. Managed Noiz clients can ask the Noiz support team to make an additional version available.

Click Save to apply the mode and version. ISPConfig rebuilds the site's configuration within roughly a minute.

Step 2: Restrict file access with PHP open_basedir

The PHP open_basedir field confines PHP file operations, such as opening, reading, writing and deleting, to a set of directories. If a script is exploited, this stops it wandering into other parts of the file system. ISPConfig manages this for you and pre-fills the field from a server-wide template, which normally covers the site's own web, private and tmp directories plus a small set of shared system paths.

1. Still on the website, open the Options tab.
2. Find the PHP open_basedir field.
3. In most cases, leave the pre-filled value in place. It already limits PHP to the site's own tree.
4. If the site genuinely needs access to an extra directory, add it to the existing value and separate paths with a colon (:). Do not remove the paths ISPConfig placed there, or the site may stop working.
5. Only if you deliberately need no restriction at all, type the single word none. Leaving the field empty does not disable it. Removing the restriction is not recommended.

Because open_basedir is an INI_ALL directive, it can also be tightened further inside your application if needed, but the panel field is the right place to set the site-wide boundary.

The template that fills the field is a server administrator setting, in a second PHP open_basedir field under System > Server Config on the Web tab. It uses the placeholders [website_path] and [website_domain], which ISPConfig expands per site. Changing it there changes the default for sites created afterwards, so it is the place to adjust if every site on the server needs the same extra path.

Step 3: Add hardening directives in Custom php.ini settings

Open the field

1. On the website's Options tab, scroll to Custom php.ini settings.
2. This is a free-text box that accepts ordinary php.ini syntax, one directive per line. Any PHP directive snippets an administrator has defined under System > Directive Snippets are listed as Available PHP Directive Snippets beside the box, and clicking a name inserts its contents at the cursor.

A recommended baseline for PHP 8.x

The block below is a conservative starting point that improves security without breaking most common applications. Paste it into the Custom php.ini settings field and adjust to taste. Lines starting with ; are comments.

; Do not reveal the PHP version in response headers
expose_php = Off

; Never show PHP errors to visitors on a live site; log them instead
display_errors = Off
log_errors = On

; Switch off the highest-risk shell and process functions
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec

; Harden session cookies (cookie_secure needs the site served over HTTPS)
session.cookie_httponly = 1
session.cookie_secure = 1
session.use_strict_mode = 1
session.cookie_samesite = "Lax"

Notes on the choices:

• disable_functions is the core of the hardening. The functions listed above let PHP run operating-system commands or spawn processes, which is rarely needed by normal web applications and is a favourite of injected malware. Because the directive is INI_SYSTEM, once ISPConfig applies it a compromised script cannot switch it back on.
• session.cookie_secure = 1 tells browsers to send the session cookie only over HTTPS. Set it only if the site is served over HTTPS, which every Noiz site should be. If the site is still plain HTTP, secure that first, otherwise sessions will break.
• Keep disable_functions on a single line. If you list the directive twice, only the last line counts, so add all function names to one comma-separated list.

Stricter options to test carefully

The following directives increase protection further but are more likely to break a specific application, so add them one at a time and test after each.

; Block PHP from opening or including remote URLs
; (allow_url_include is already Off by default; allow_url_fopen
;  breaks apps that fetch remote URLs with file functions)
allow_url_fopen = Off
allow_url_include = Off

; Turn off uploads entirely if the site never accepts file uploads
file_uploads = Off

; A wider function block list; some backup and imaging plugins need
; a few of these, so remove any that your application actually uses
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec,show_source,proc_get_status,proc_nice,proc_terminate,dl,symlink,link

Do not paste the baseline disable_functions line and this wider one at the same time. Choose one list, since the later line would override the earlier one.

Save and apply

1. Click Save.
2. Wait about a minute for ISPConfig to rewrite the site's PHP configuration and reload the PHP-FPM pool.
3. Load the website in a fresh browser tab and click through its main pages to confirm everything still works.

Note that if a server administrator later changes the global php.ini, those global changes do not reach a site that uses this field until the site's own configuration is rewritten. Saving any change to the website in ISPConfig does that. ISPConfig can also do it unprompted: a server setting called Check php.ini every X minutes for changes, under System > Server Config on the Web tab, re-reads the system php.ini files on that interval and rewrites the per-site files belonging to websites that carry custom settings. Setting it to 0 switches the check off.

Step 4: Verify your settings took effect

Do not assume a directive is active just because you saved it. Confirm it.

1. Create a temporary file in the site's document root, for example phpcheck.php, containing only <?php phpinfo();.
2. Open https://yourdomain.com/phpcheck.php in your browser (using your real domain).
3. Check the PHP Version shown at the top matches what you selected.
4. Use your browser's find function to locate disable_functions and confirm the Local Value lists your functions. Check expose_php, display_errors and the session.cookie settings the same way.
5. For a real test of disable_functions, confirm a disabled function actually fails rather than only appearing in the list. A short test that calls, for example, exec('id') should produce an error in the PHP log, not run the command.
6. Delete phpcheck.php immediately afterwards. A left-behind phpinfo() page leaks configuration details to anyone who finds it.

For self-managed server administrators

If you run your own Noiz server with root access, you have additional levers beyond a single website:

• Set safe defaults for every site. Applying a baseline disable_functions and expose_php = Off in the global php.ini of each PHP version means new sites are hardened from the start, while the per-site Custom php.ini settings field is used only for exceptions. Apply it to the web-facing php.ini files only. Never put disable_functions in the command-line php.ini, because ISPConfig runs its own maintenance scripts through the CLI binary and stops working correctly if those functions are taken away from it.
• Add and retire PHP versions under System > Additional PHP Versions, so clients can move off end-of-life releases.
• Remember the mode difference when checking your work. For Fast-CGI the site's values are written to a per-site php.ini read at PHP startup; for PHP-FPM they are written into the site's pool as php_admin_value and php_admin_flag entries, which is why INI_SYSTEM directives such as disable_functions are enforced and cannot be relaxed by a script.
• Test after every global change, because a directive that is safe for one application can break another.

Troubleshooting

• The site shows a blank page or a 500 error after saving. A directive is probably too strict. The usual culprit is an over-long disable_functions list that removed a function the application needs. Go back to the Custom php.ini settings field, shorten the list to the conservative baseline, save, and test again. Add functions back one at a time.
• The Custom php.ini settings field does nothing. Confirm the site's PHP mode is PHP-FPM, Fast-CGI, CGI or SuPHP. The field is ignored under Mod-PHP. Change the mode, save, then re-enter your settings.
• A value shows in phpinfo but is not enforced. Give ISPConfig a minute to rebuild the configuration, then reload. If a function still runs despite being in disable_functions, check the list is on a single line and not duplicated lower down, and that the site really is on PHP-FPM or Fast-CGI. If it still will not enforce, ask the Noiz support team to confirm the mode and PHP version on the server.
• Sessions or logins stop working. This often follows session.cookie_secure = 1 on a site that is not served over HTTPS. Secure the site with a certificate, or remove that line until you have.
• The Options tab is not there at all. The tab is shown to the ISPConfig administrator, and to a reseller only when Reseller can use the option-tab for websites is ticked under System > Interface Config on the Sites tab. A client-level login never sees it, so such an account can still change the PHP mode and version on the Domain tab but cannot reach either hardening field. Managed Noiz clients should send the directives they want to the Noiz support team to apply.
• You need a PHP version that is not in the list. Additional versions are installed at server level. Managed Noiz clients should request the version they need from the Noiz support team.

If you get stuck, or you would like Noiz to review a hardening profile before applying it to a live site, open a support ticket with the Noiz support team. Include your domain name, the PHP mode and version the site is using, and the exact directives you added to the Custom php.ini settings field, so support can reproduce and check the behaviour quickly.