I was thinking about CORS and preflight caching lately, and came upon these previous discussions:
http://lists.w3.org/Archives/Public/public-appformats/2008May/0039.html http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0228.html Presumably there are a numerous others which I haven't read; so apologies if my suggestion has been brought up previously. Still, I thought to present a solution strategy in case there's anything of use in it. ( 1. ) The simplest idea is to add mask and depth headers: Access-Control-Policy-Path: /path/to/api Access-Control-Policy-Mask-Path: /private Access-Control-Policy-Mask-Path: /product/partner Access-Control-Policy-Mask-Depth: 2 In this scheme, the intent would be that, assuming * for Access-Control, and URL which is up to two levels more-deeply nested than /path/to/api is publicly available and preflights may be cached as a group. So, this includes URLs such as /path/to/api/products /path/to/api/products/red - but not /path/to/api/products/red/small Additionally this imposes that, regardless of depth, the access-control does not apply to any url on or in /path/to/api/private or /path/to/api/product/partner In this scheme, both Mask-Path and Mask-Depth are relative to the Policy-Path. By applying a list of mask sub-paths and restricting depth, security can be relaxed for only a small range of endpoints. ( 2. ) As a possible an extension to this, we could introduce sequential sets where each Access-Control-* header refers to the Access-Control header which appears most recently before it. i.e. Access-Control-Scheme: PUBLIC_API Access-Control-Allow-Origin: * Access-Control-Policy-Path: /path/to/api Access-Control-Policy-Mask-Path: /private Access-Control-Policy-Mask-Depth: 2 Access-Control-Scheme: PRIVATE_API Access-Control-Allow-Origin: scheme://internal.host:port Access-Control-Policy-Path: /path/to/api/private Access-Control-Policy-Mask-Path: /private Access-Control-Policy-Mask-Depth: 5 ( 3 ) If elements of the prior two concepts were acceptable, it would be possible for either an endpoint or a client-context (ex: a web service or a page calling some ajax) to define a single broker for the given service. This could be by either the calling 'page' or the service defining a header: Access-Control-Scheme: PUBLIC_API Access-Control-Broker: scheme://internal.host:port/[optional] The broker can in turn only assign access control to paths more deeply nested than itself or sub-domains extending further left toward the scheme (scheme://sub.internal.host:port). In this case, the "Access-Control-Scheme" must match one provided by the broker or else access will default to the current practice based on return headers. If the service returns an Access-Control-Broker, then a second preflight would be initiated. It is preferred that a broker is known for clients implementing an API, or may be queried somehow, allowing them to avoid access-based interaction with services. This should allow larger organizations to have fine-grained control over multi-variant ranges and has the benefit of keeping preflight contained to dedicated areas which may have the side-effect of increasing security over current methods. At the same time, scripting services becomes more convenient for UA which support this but are not less capable of defining their own Access-Control per-endpoint. One further note, any access-control broker should only be allowed to specify a scheme for sub-domains of it's own host. Any path-based broker should not be allowed to specify a scheme outside of it's current host, including sub-domains. This stated with the idea that the root-most URLs shall hold precedence but overrides are possible only for deeper URL structures. Thus service.domain.com/team1/api cannot define a broker to service.domain.com/team2/api or subsrv.service.domain.com/team1/api Some aspects of this proposal could most likely be enhanced and/or simplified. There's quite a bit I do not know about the current state of discussion in this area. Simply, I hope that we'll eventually have a cleaner interface towards securing CORS and automating access across networks. Cheers, -Garet Claborn ga...@approach.im
