So basically you say. Nobody cares and does not see it as an issue. 99% will just install it as it is and not bother about security and best practice.
Sure i can talk with support to learn how the file structure works, but this is a general problem, and i am not motivated to fix it, seeing in this forum how nobody even sees this as an issue, or it its a open bug over 6 month.
It just shows the culture and architecture is not good. and i am sure there are a lot of good developers involved. i just don’t understand why this is just ignored.
I am a developer and could help fix it, but i have no hope as it will be too much bureaucracy to get that anywhere close to be part of the official installation.
The solution for now is “hope that nothing breaks” and the developers don’t shoot themselfs in the foot.
How many installation does matomo have ?
A quick googlesearch gives about 10k to 100k WP Plugininstalls for Matomo, and 1Mio Websites in 190 countries. This is more than a handful of users.
Shouldn’t security be some concern and not just be ignored and swept under the rug ?
If by accident some malicious files are installed in the node_modules or similar public folders and not checked for apache/php environment and only secured for node (which even should be serverside and never public in a node.js server).
Why am i the only one concerned by this with 1Mio users ? Something is fishy…
You can open an Issue in Github for a hint to this possible problem. Or you can open an Pull request and post a possible solution. First you should check whether your assumptions are true. The best way to do this is with an example.
Please give us an example, that other can imitate.
I will make a use case example of worst case scenario with some simulated situation.
(similar to the log4j bug affecting millions by having code executing in unexpected places. Using Murphey s law. What can go wrong, will eventually go wrong. Its not a matter of if. But when)
I am over dramatic to make it more clear. Its not a short term problem but a long term architecture flaw.
I will make examples and pull request or tickets. Whichever fits best to the example. Maybe a pull request with a final solution is not possible at the moment as it would break things like
What we did placing everything behind Cloudflare and we only give access to the the neccesary files matomo.php etc. All the rest is only accessible for interal traffic.
That’s quite good and mostly solves solution 1 using htaccess as a sandbox.
Maybe a first step could be to have this file with good comments as a. .Htaccess.Example. (In the main github Version included)
Similar to phpmyadmin with an example configuration which you have to rename to get it running. And updates will then not override this manual config.
With the instruction to rename to… htaccess or integrate with an existing one.
Or with the installer wizard which is doing database config etc. Already and create a custom htaccess file automatically with the correct path. And the wizard could ask if you want to turn on sandbox for htdocs. Or not and avoid side effects.
In WordPress some Plugins like sucury can be too much and break features. So the final decision should be at the admin for matomo who knows the environment and side effects.
But the default would still raise awareness, even if the admin chooses to skip this step.
In this forum sometimes… htaccess is avoided as it can have side effects when it’s used with WordPress in the same folder. But i think it should be possible to find a compromise without side effects. Usually the htaccess is inside a matomo folder and the htaccess rules don’t t spill outside.
My point is. This configuration should be the default and not for the 1% experts. Security is a problem especially for beginners. A sysadmin can always add some Firewall etc.
I have the same problem with WordPress. As with a default install it is very likely to catch malware in 3 month, but with some simple configuration and Plugins the risk to get malware is nearly zero.
That’s my pesonal opinion (having some experience with that topic) but open for discussion.
Thanks for collecting that useful information, not so easy to find as a beginner after initial installation.
I see one part even tries to explain which file are important and should be whitelisted in the htaccess.
Use web server features to restrict access to a few files only, and restrict by IP address
If you use an Apache web server, it’s easy to use .htaccess files to restrict access to Matomo to your IP addresses, or many more options. Check out the examples.
When you restrict access to files, please note that you need to allow external access to the following files:
matomo.php, matomo.js, piwik.php, piwik.js,
and to the URL index.php?module=CoreAdminHome&action=optOut and for the files plugins/CoreAdminHome/javascripts/optOut.js and favicon.ico to make sure the opt-out iframe will work without password prompt.
and to js/container_*.js files for TagManager to deliver the container files
and to plugins/HeatmapSessionRecording/configs.php if you use Heatmaps or Session recordings
So this information is hidden in the forum. Just took a while to surface.
Technically maybe the best practice could be to put a .htaccess.example in the github as a starting point and admins who want to improve security can use it to make a whitelist.
Then more can be aware of this and less surprises.
I will try these recommendation and sometime make a pull request with an example htaccess which should not cause side effects.
Thanks for the discussion. And just to clarify, Matomo already creates automatically the .htaccess to protect the installation. The problem is more apparent for NGINX where this doesn’t apply. For Apache it shouldn’t be a problem with the .htaccess.
You are correct that having all files in the public folder (htdocs in Apache) is not a good practice from a security standpoint. If sensitive information such as configuration files or source code is stored in the public folder, it can be accessible to anyone who visits the website.
To improve the security of your Matomo installation, you can move the sensitive files outside of the public folder and configure Matomo to access them from there. This is also known as a “non-public” installation.
To do this, you can create a new directory outside of the public folder, for example, /var/www/matomo, and move all files except the ones that should be publicly accessible (such as index.php, piwik.js, piwik.php) to this directory.
Next, you can edit the index.php file in the public folder and update the PIWIK_INCLUDE_PATH constant to point to the new location of the Matomo files. For example:
sqlCopy code
define('PIWIK_INCLUDE_PATH', '/var/www/matomo/');
Finally, you can configure your web server (such as Apache or Nginx) to point to the index.php file in the public folder as the entry point for the Matomo installation.
As for blocking files with an .htaccess file, it is possible to do so, but as you mentioned, it can be difficult to maintain and may not provide full protection. It is better to follow the best practice of having sensitive files outside of the public folder to reduce the attack surface.
Yes i understand your idea, and as a developer i can make a workarround and fix it, worst case read the sourcecode to figure out what is active and what are build files.
my point is, it should be easier to do it secure (99% of users) than to make it insecure and fix the installation (1% of admins) , who do it already as they know the “problem”.
Nobody will download the default installation with the wizard from github, and then move files arround like you explained. but just keep it and leave the attack vector.
The point is “defensive programming”, making it impossible to get an exploit like log4j, which could be done here with bad chain of events (eg. somebody uploads malware php into a npm modules which ends up in the node_modules folder).
the .htaccess “sandbox, whitelist” is the most practical approach for now.
Same here, in my apache install (linux gentoo) no htaccess was created automatically. only some in config folder to blacklist access. but no htaccess in htdocs to whitelist files.
i need to read the code with the installer-wizard if it tries to copy or create this file.
as far as i can see this is all manual. and only the config is protected. but that’s not the discussion here.
I it was there, i would not even have started this discussion.
Some search in github shows there is indeed a file to create and put a htaccess there.
But when i used the wizard it connected DB etc. but didnt write the .htaccess file to my server.
So it seems to be a bug, which i was lucky to trigger with my server setup. (Shared Hosting)
Still odd we are now down 21 comments in this thread, and it seems all I question already exists, and its a real bug in the installer wizard, maybe problems with file access rights to save to disk.
The second answer should have been in this thread.
“… it already exists, you have a bug in your installation …”
I need to make a new Install on another server and see if the htaccess is created, and why it is not on my main server.
Then it just would be a bug report if the wizard cannot write to disk or similar .
Hi!
I’m following this discussion since the start as I found it interesting that no .htaccess was created in the Matomo install directory three month ago when I first installed it on the server.
I do have it in:
/config
/js
/lang
/tmp
All other directories and the main install directory do not have one.
I’m still not clear if they are missing or not and how to create them after the installation if necessary.
I would be grateful if this could be explained better.
I have other things higher priority but i will make some tests in a few days. new install and debug what’s going on with the missing htaccess. (2 different hosters, to see if its some funny side-effect)