Re: CORS in PWA's

Hi,

CORS is a known nuisance for a lot of folks and the Same-Origin Policy
is the fundamental security mechanism for the web. There is no way to
work around it when you are part of the web (e.g., a web app).

The web platform also does not provide a way to figure out whether a
URLs target is on the public internet or part of the user's internal
network (for security reasons, again).

So, an additional risk is that a website might end up reading stuff that
is behind the user's firewall / NAT is still unmitigated here and likely
not ever to be addressed.

If your use case is RSS or Podcast (which I saw mentioned specifically
in your linked blog post), you will have to find a cooperative CDN that
sends `Access-Control-Allow-Origin: *`.

It has been tried to address the intranet case more restrictively in
<https://wicg.github.io/cors-rfc1918/>, but with AFAIU little success
due to existing web content.

Hope this helps,
Frederik


P.S.: This will be my only post in this thread.


Am 19.08.20 um 12:53 schrieb Daniel Betteridge:
> Hello!
> 
> I’ve done a bit of a search of the mailing list and aside from a
> somewhat antagonistic post
> (https://lists.w3.org/Archives/Public/public-webapps/2017OctDec/0044.html)
> 
> I couldn’t find a thread on this topic, given the goal of client side
> web-apps to incorporate a lot of functions of ‘Native’ applications one
> of the big sticking points is the CORS restrictions that browser based
> applications face that their Native counterparts do not.
> 
>  
> 
> I wrote a bit about the issue I was facing
> (https://danielbetteridge.com/a-lost-cors/) but essentially, If I want
> to write a PWA that uses any third party resources I need to either work
> only with servers configured with CORS (less then I’d like) or create a
> proxy to work around the issue.
> 
> What are the barriers or issues with (for example) allowing GET requests
> to a different origin within specifically an installed PWA where the
> fetch request has credentials set to “same-origin”, this would allow a
> lot of the functionality that is currently blocked (RSS feeds, Podcasts
> etc).
> 
> I did read Boris’s response in the link above, but unsure how this is
> congruent with non-browser usage of resources. If a webpage relies on
> CORS to secure its resources, are they not effectively open to anyone
> who uses something other than a browser to access the site such as
> CURL/Custom browser without CORS etc.
> 
>  
> 
> Thankyou!
> 
> Daniel
> 
>  ____________________________________________________________
> Electronic mail messages entering and leaving Arup business systems are
> scanned for viruses and acceptability of content.**

Received on Friday, 9 October 2020 08:52:28 UTC