New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
POST
to matomo.php
Endpoint Returns 204 When Setting An Origin
Header Not On The cors_domains
#19116
Comments
POST
to matomo.php
Endpoint Returns 204 When Setting An Origin
Header Not On The cors_domains
POST
to matomo.php
Endpoint Returns 204 When Setting An Origin
Header Not On The cors_domains
should we assign this issue to the 5.0 milestone, since it's breaking changes? |
I'm not sure. Thinking of tracking I'm wondering if 204 is maybe actually the correct response since the tracking request was processed and we would want to avoid that because of https://github.com/matomo-org/matomo/blob/4.10.1/js/piwik.js#L2843-L2850 we would retry that tracking request. A 204 would describe exactly above. Request was executed but no response/content. AFAIK when sending a tracking request and there is a CORS error then the request itself was still executed. It's only that the response wasn't readable for the client. So we'd want to make sure to not send every tracking request twice. |
I guess that depends on the expectation. I would actually also assume that a configured cors domain would also disallow requests coming from other origins. In that case it would be correct to send a |
You can see this in the examples on https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS as well that these send HTTP 2XX (200 and 204) headers. And the browsers decided if the client can read the response. Also
The browser console already shows correctly when a CORS error happens |
@Zozman What exactly was you intention when creating the issue? |
@sgiehl Essentially our view is if an Origin not on the |
@Zozman Ok, so it's around "blocking" requests. Personally I would avoid reusing the CORS config for this. As there could be good reasons for having another set of domains in the CORS config and in the list of domains you want to allow as tracking origin. Also how would you handle requests without an origin? Should those be discarded in any case then? Note: In terms of security this won't have much benefit. If someone wants to send requests to you endpoint with random data, they can do it nevertheless by sending an origin header. |
@sgiehl I'm just confused about the fact that there's an explicit list of domains that should be allowed to send data to a Matomo instance and then treating requests from not those domains as OK. Without this, someone could setup malicious JavaScript on any website on the internet to hit a site's Matomo endpoint all day and get back successful responses. I understand anyone can hit it, but |
I'm not very deep into the CORS specification. But either we should fully block a request if the origin doesn't match and return a 40x status. Or we allow tracking from any source and return a 204, like it currently is. And yes, in theory any website could start tracking to a random instance. But the website configuration allows to discard all requests that don't match the configured domains. So you can at least prevent tracking random urls. Anyway. I would suggest to introduce a new config that allows to enable blocking requests from origins that are not on the CORS list. That way anyone who wants to use that could enable it easily. |
According to the documentation in the Matomo FAQ, CORS settings can be set by setting the
cors_domains
array in theconfig.ini.php
to only allow certain domains to interact. However even if this is set, when sending aPOST
request to thematomo.php
endpoint with a domain in theOrigin
request header that is not on the list still returns a204
instead of an error.Expected Behavior
When the
Origin
request header is set to a URL not on the list, the response should be some sort of4xx
response.Current Behavior
Response is a
204
Possible Solution
Set behavior to return a
401
in this instanceSteps to Reproduce (for Bugs)
cors_domains
in theconfig.ini.php
to your domain.System
->General Settings
page under theCross-Origin Resource Sharing (CORS) domains
section.POST
request to the/matomo.php
endpoint with theOrigin
header set to a value not in thecors_domains
array (for example,https://evil.site
204
.Context
This bug could allow malicious actors to hit endpoints from environments outside the allowed websites.
Your Environment
4.9.0
8.0.17
4.0.9-apache
)100.0.4896.127
and using PostmanThe text was updated successfully, but these errors were encountered: