I am running my chrome instance with the --user-data-dir="folder" --disable-web-security flags, but apparently the cross origin policy is still being enforced. I can't access the elements of an iframe that's from another domain.
Is there any solution to actually disable the check for a same-origin policy, once and for all? Or is there any browser that can properly do that?
Related
I try to set up the permissions policy header for the websites I managed.
Here's the header retrieved from the network tab of my Firefox browser:
permissions-policy:
accelerometer=(), ambient-light-sensor=(), autoplay=(self), battery=(), camera=(), display-capture=(), document-domain=(self), encrypted-media=(), fullscreen=(), gamepad=(), geolocation=(), gyroscope=(), layout-animations=(), legacy-image-formats=(), magnetometer=(), microphone=(), midi=(), oversized-images=(), payment=(), picture-in-picture=("https://video.website.org"), publickey-credentials-get=(), screen-wake-lock=(), speaker-selection=(), unoptimized-images=(), unsized-media=(), sync-xhr=(), usb=()
When I browse this website I'm able to do everything what should be allowed for.
But I don't know if my rules are taken into account? I have no parsing error in my console log (only comments that some features are not recognized in Chrome).
If I go in my google Chrome (Version 103.0.5060.134 (Official Build) (64-bit)) settings (... > Privacy and security > Sites settings) or in my Firefox (103.0 (64-bit)) settings (3_, Privacy and Security > Permissions) I can't see any rules related to my header: it's like they are ignored.
My questions are:
should the Permissions policy header be visible in the browser configuration?
If yes, why my rules are not visible in my browsers? Are they not well parsed? I don't have any console error
If no, how can we check that our Permission policy header is well applied in Firefox and Chrome?
Thanks in advance for your help
Mat
I'm not sure what you mean by "be visible in the browser configuration". Where do you expect to see it? (Permissions-Policy headers are not going to affect whether the user has enabled/disabled features directly in the browser, as they only apply for the current request - e.g. if your PP header allows geolocation, if the user has disabled it then the browser will honour the user settings)
You say that you can see the Permissions-Policy header being returned. The only thing left is for you to do is test that the policy is being applied (e.g. can your site autoplay videos? If you change the header to 'autoplay=()' is autoplay prevented?, etc.)
We receive mp3 voicemails in Gmail. Starting today, all computers using Google Chrome can't play mp3s found in Gmail. This doesn't affect other sites that host mp3s.
Upon further inspection, the console reports:
Refused to load media from 'https://mail.google.com/mail/u/...' because it violates the following Content Security Policy directive: "media-src https://*.googlevideo.com/videoplayback/".
Is Gmail not following its new CSP policies? Is any work around other than simply downloading and playing the files?
With the Content Security Policy directive media-src https://*.googlevideo.com/videoplayback/, media files from sources different to https://*.googlevideo.com/videoplayback/ can't be played in the <video>/<audio> tags embedded into page.
Even you load media by ajax and create <audio> tag with blob:-Url, it will be blocked by above CSP.
It's not a browser dependant, that's how CSP is work.
With the current CSP restrictions, mediafiles can be played only in the isolated browsing contexts like <iframe>/<object>/<embed>.
I don't know is GMail made it intentionally or occasionally, but only browser extensions using nested browsing contexts can play media in such conditions.
In the end, I created a Chrome Extension with XMLHTTPRequest to get around CSP and to play the mp3 without a direct download.
I released a Chrome Extension called GPlayer. Waiting on Google to approve. I believe the future link is https://chrome.google.com/webstore/detail/obdmmgdlafadeehmbmcmoggnaokehnaj
Github link - https://github.com/TriStarGod/GPlayer
I am upgrading jwplayer to 7.4.4 with hlshtml and default mode as html5 settings.
My player is working fine in firefox. But in chrome its giving error : cannot load m3u8 crossdomain access denied.
Usually caused by a firewall blocking your access. On IE you can try: Go to "Internet Options" > "Secuirty" > "Internet" > choose "Custom Level" and scroll down to "Miscellaneous". One of the options should be "Access data sources across domain" - set this to "Enable".
If it is already enabled then it is likely that there is a firewall blocking you.
OR
When you get the error, do you have a shield on the right side of your address bar? You should be able to click on that and override the blocking for mixed content. Otherwise, you can force start the browser instance without the check through terminal, though, at that rate, would probably be easier to just use Safari until they get the cross-domain issue fixed.
I have a download link like so:
Foobar
This works fine when downloading a file on the same server, but when downloading from another server (Azure blob storage in this case) the filename stays as "foo.xls", even though the HTTP response comes back with the following header:
Access-Control-Allow-Origin: *
Is this by design or is there potentially another header I can to add to the HTTP response to get this to work?
Yes, it is by design that the CORS headers have no affect on the download attribute. There are only two browsers that support the download attribute, Firefox and Chrome, and both browsers have a different policy on cross-origin files.
Chrome versions prior to 65 actually did allow the download attribute on cross-origin files, without CORS headers, but Firefox chose not to, citing potential social-engineering attacks.
MDN documents this behavior for Firefox 20 under the download attribute section for the a tag, behavior that has not changed since.
In Firefox 20 this attribute is only honored for links to resources with the same-origin.
This Bugzilla report discussed the security concerns and the possibility of using CORS.
When the user clicks such a link, the user will be prompted if they
want to download. It seems very easy for the user to make the mistake
of thinking that something on the original website is being
downloaded, and not something from bank.com.
Would it be possible to implement it with same-origin and CORS
(Access-Control-Allow-Origin) in mind if you are questioning cross origin
security? This is very useful feature for web applications (create Blob
using JS and let user download it with some meaningful name)
Google was opposed to using CORS for this.
There's also this Bugzilla report, which summarizes their decision from the other bug report.
Also, cross origin downloads are working perfectly in Google Chrome.
Yes, and we think they're adding security bugs by doing that.
The Bugzilla issues don't seem to rule-out the possibility of using CORS for cross-origin download attribute support in the future, but right now using CORS headers does not do anything for the download attribute. It's possible that if other browsers start supporting the attribute, a consensus may yet be reached.
For sake of completeness, there is of course the Content-Disposition header which you can use to force a download from the other domain, but this does not provide the same functionality as the download attribute. It does have better browser support though.
I'm using chrome extension to add in https://* pages, but when I want to load pages from http://*, chrome blocked the page saying:
[blocked] The page at https://* ran insecure content from http://*.
So I wonder, is there any method or API to avoid such situation?
You cant unless you change the chrome security policy which can't be done from code, each user would need to do it and will be a security risk for those users.