Re: [w3ctag/design-reviews] CORS-RFC1918 (#572)

Apologies for the followup...

Another deliberate exclusion here is that servers that are already in a "private" context can attack each other without engaging the additional consent protections.  My understanding is that this exclusion exists for two reasons: 1. because we assume that these services can already talk to each other, and 2. so that enterprise services can "talk" to each other.  

Lateral communication is not a guaranteed property of the system.  An RFC 1918 address (i.e., IPv4) might not naturally be able to access an IPv6 ULA.  Good network-level controls might aim to prevent lateral communication between servers in a network, so that even if clients can talk to any server, servers can only talk to other servers that they need to.  These safeguards might exist to limit the ability of a compromised service attacking other services.

The same applies to services running on localhost.  The application that maintains that service can probably talk to other services on localhost, but this is not always the case.  A browser might be given access to all local ports, but specific applications might be prevented from unfettered communication.  Using the browser to circumvent those restrictions might not be something the administrator/user wants.

Acknowledging that these choices are deliberate would be good.  FWIW, I don't think that it would hurt to treat loopback to loopback as a "private" request, though the compatibility risk involved with restricting lateral movement within networks probably makes the same constraint harder to apply at the next layer out.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/572#issuecomment-810809858