It seems that various JSON configuration files are easily viewable by requesting them with a simple GET request. Some examples of these are:
Some various files I've observed:
There could be useful to an attacker trying to monitor the patch version of Matomo sites, so the access settings should be made less permissive so that JSON files aren't as open to the web.
A useful command to enumerate over these from the core project isfind ./ -iname '*.json' | egrep -v '(vendor|lang|node_modules)'
FYI noticed originally json
was added to fix some tests in https://github.com/matomo-org/matomo/commit/903b870466b62e8a655a0f6564d052583c0fb7ec#diff-dddd74c8019f3e240dad1e60bc6ffbdd906ad7fa396b3e272a493f5b4af0c5c7
I suppose we could check through all the tests and see if we can maybe remove json
now. package-lock.json
we'll soon actually remove from the release directly but then they might still exist when someone uses submodules (which we do in some places so far). Possibly could otherwise also just specifically disallow some json files like plugin.json
and package.json
etc
So here we'll remove json
from https://github.com/matomo-org/matomo/commit/903b870466b62e8a655a0f6564d052583c0fb7ec#diff-dddd74c8019f3e240dad1e60bc6ffbdd906ad7fa396b3e272a493f5b4af0c5c7 and check if tests still pass. If that's the case we could proceed. If tests don't pass, comment here what the problem is and likely we won't do anything in that case.
Pushed the change here: https://github.com/matomo-org/matomo/compare/m18128?expand=1
Let's see if tests are failing or not.
@tsteur Seems the test failures are unrelated to the changes, so seems we could remove json from the list of static files to be served. But it could create possible regressions with third party plugins that might try to load json files on purpose for any reason.
Do you know what such a use case for a third party plugin might be? Are you aware of any plugin? I can't really think of many use cases and I assume the workaround would be for people to use a proxy through php to get this file. It may be fine to just disable it and mention it in developer changelog. That's just though because I can't think of any use case for it but that doesn't mean there aren't any.
I'm not aware of any plugin that needs it. And if so, it should be easy to circumvent it.
Mentioning it in the developer guide should be good enough I guess. Will set up the PR.