S3 CORS configuration superseded by public access settings?

For a little test web app, I was trying earlier to set a CORS configuration on an S3 bucket. I had no ACLs and public access set to the following:

(all checked except the last option) AFTER I had set the following policy:

{
    "Version": "2012-10-17",
    "Id": "Policy1559671538244",
    "Statement": [
        {
            "Sid": "Stmt1559671517813",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::somename/*"
        }
    ]
}

Access to S3 was working fine, my local browser could access all the uploaded assets. However, then I needed to activate CORS for a certain page and I added the following CORS configuration:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>HEAD</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>Authorization</AllowedHeader>
</CORSRule>
</CORSConfiguration>

I repeatedly got the error No 'Access-Control-Allow-Origin' header is present on the requested resource. It did not work, until I deactivated all block public access options. This was unexpected. Now I have re-activated the relevant Block public access options and it seems to keep working. This leads me to believe that S3 interprets the CORS configuration as a new public bucket policy or as an ACL. And that therefore the block public access settings supersede also the CORS configuration. I have not seen this mentioned in the documentation. Does anyone know more about this?