Access control by origin header not working?

First a disclaimer - it is very difficult to find any documentation about access control for web-apps, so I am possibly wrong here. But here we go anyway ...

Assuming I have a browser web-app that lets me register my pets. My pets are very valuable to me and I really don't want any other web-apps to snoop into my pet collection even if I am logged in to my POD with some third party web-app.

How do I prohibit other web-apps from accessing my pets? Well, first of all I make sure that access control for my /pets folder is "specific" according to the data browser, which seems to be identical to creating a .acl file for the container. Then what?

At https://www.w3.org/wiki/WebAccessControl#Giving_a_specific_resource_access_to_an_Origin the following is suggested:

[] acl:accessToClass [ acl:regex "https://bblfish.solid.example/.*" ];  
   acl:mode acl:Write; 
   acl:origin <https://apps.rww.io>  .

So I add acl:origin <https://nothinguseful.org> to verify that no existing app, not even my own pet-app, have access and try to work with the data from the pet-app ... and still have complete access.

The ACL file is located at https://elfisk.solid.community/places/hobby/.acl and contains:

@prefix : <#>.
@prefix n0: <http://www.w3.org/ns/auth/acl#>.
@prefix hobby: <./>.
@prefix c: </profile/card#>.

:owner
    n0:accessTo hobby:;
    n0:agent c:me, <mailto:jw@elfisk.dk>;
    n0:defaultForNew hobby:;
    n0:mode n0:Control, n0:Read, n0:Write;
    n0:origin <https://nothinguseful.org>.

The HTTP request sent is:

PUT https://elfisk.solid.community/places/hobby/yyy HTTP/1.1
Host: elfisk.solid.community
Connection: keep-alive
Content-Length: 347
authorization: Bearer ...
Origin: https://solidrc.azurewebsites.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
content-type: text/turtle
Accept: */*
Referer: https://solidrc.azurewebsites.net/Home/Locations
Accept-Encoding: gzip, deflate, br
Accept-Language: da-DK,da;q=0.9,en-US;q=0.8,en;q=0.7,sv;q=0.6,nb;q=0.5
Cookie: connect.sid=...
DNT: 1

@prefix : <#>. ... more turtle stuff ...

As you can see, the origin header is Origin: https://solidrc.azurewebsites.net - which is not matching the acl:origin value.

Is this a bug or me completely misunderstanding it all?

Start by reviewing the linked Web Access Control guidance and the supplied ACL at /places/hobby/.acl alongside the PUT request's Origin header. Trace the server's authorization handling for acl:origin and verify whether a non-matching origin is denied, while distinguishing browser CORS behavior from server-side access control. Done means the behavior is explained and, if it is a bug, covered by a reproducible test.