CORS, Preflight caching and Access-Control-Policy-

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
garet@approach.im

Received on Thursday, 19 June 2014 09:29:41 UTC