Securing the docroot directory

Product Support Mautic 6 Install/Upgrade Support
1

Hello!

I’m an ops guy tasked with creating a mautic instance for our company. I’ve tried two methods: via composer (mautic/recommended-project), and by downloading a release package from github. Both were version 6.0.9 - the latest version we can use for now, because of php version constraints internally.

Both install methods contained a large number of “extra” files in the docroot folder, I mean php, twig, yml - files that should not be accessible. Most of our projects use symfony, where you only have the front controller there and some static assets, so this was suprising.

I failed to find documentation or a guide on how to avoid this, to only make accessible what is neccessary. Can someone help me with this?

3

I checked both official Mautic 6.0.9 distributions. Your observation is correct:

  • The ZIP release uses a flat application root containing index.php, application code, plugins, templates and configuration-related files.
  • The official Composer template explicitly defines docroot/ as its web root and installs the Mautic core under docroot/app, with plugins and themes also below docroot/.

This is therefore the intended Mautic 6 layout, not an installation mistake.

With Apache, the supplied .htaccess files provide part of the protection: the root rules deny direct access to .env, Composer files and PHP files other than index.php and upgrade/upgrade.php; app/, bin/ and var/ contain rules denying web access. Those protections only apply if Apache allows .htaccess overrides.

Nginx does not read .htaccess files at all, so an Nginx deployment must implement equivalent rules explicitly. In particular, it should deny direct access to app/, bin/, var/, hidden files and source/configuration file types, while permitting only the required static assets and routing application requests through index.php.

I would not move the Mautic directories manually, because the Composer layout and updates expect this structure. Instead, please confirm whether the deployment uses Apache or Nginx and share a sanitised virtual-host configuration. We can then verify that the supplied protection is active and identify any paths, such as template or YAML files outside protected directories, which need an explicit deny rule.