On 8 June 2015 at 21:30, Nottingham, Mark mnott...@akamai.com wrote:
A header denoting site-wide metadata would work for this too, of course, if
folks were comfortable with the security properties of doing that (as well as
the potential response overhead).
The security properties bother me
Picking up an old thread...
On 20 Feb 2015, at 12:54 pm, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Martin Thomson wrote:
On 20 February 2015 at 11:39, Bjoern Hoehrmann derhoe...@gmx.net wrote:
The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`.
I missed that. In
On Tue, Jun 9, 2015 at 6:42 AM, Martin Thomson martin.thom...@gmail.com wrote:
The security properties bother me a little. Alt-Svc is showing us
that we can't just define a header field like that without some
serious analysis.
Same goes for a site-wide file. See crossdomain.xml. However,
On 9 Jun 2015, at 2:42 pm, Martin Thomson martin.thom...@gmail.com wrote:
On 8 June 2015 at 21:30, Nottingham, Mark mnott...@akamai.com wrote:
A header denoting site-wide metadata would work for this too, of course, if
folks were comfortable with the security properties of doing that (as
On 9 Jun 2015, at 2:54 pm, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Jun 9, 2015 at 6:42 AM, Martin Thomson martin.thom...@gmail.com
wrote:
The security properties bother me a little. Alt-Svc is showing us
that we can't just define a header field like that without some
serious
additional examples [1][2][3][4].
I've never used the credentials functionality of CORS, instead passing an
Authorization header explicitly. I think we could survive without it.
I also recently ran into the CORS performance issue. CORS seems very biased
against hypermedia services, in that it doubles
On Tue, Feb 24, 2015 at 7:33 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 24, 2015 at 3:25 AM, Anne van Kesteren ann...@annevk.nl wrote:
If we only do it for this, could we combine that feature with the
existing preflight then? Support a Access-Control-Allow-Origin-Wide:
true header
On Mon, Feb 23, 2015 at 8:42 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 23, 2015 at 11:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
That combined with requiring to list
the explicit origin has worked well for CORS so far.
This could potentially help.
I don't remember the
On Tue, Feb 24, 2015 at 3:25 AM, Anne van Kesteren ann...@annevk.nl wrote:
If that's the case then I think we'd get most of the functionality,
with essentially none of the risk, by only allowing server-wide
cookie-less preflights.
If we only do it for this, could we combine that feature with
On Mon, Feb 23, 2015 at 7:15 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
On Tue, Feb 17, 2015 at 9:31 PM, Brad Hill hillb...@gmail.com wrote:
I think it is at least worth discussing the relative merits of using a
resource published under /.well-known for such use cases, vs. sending
pinned
On Sat, Feb 21, 2015 at 11:18 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Sat, Feb 21, 2015 at 10:17 AM, Martin Thomson
martin.thom...@gmail.com wrote:
On 21 February 2015 at 20:43, Anne van Kesteren ann...@annevk.nl wrote:
High-byte of what? A URL is within ASCII range when it reaches
On Fri, Feb 20, 2015 at 11:43 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Feb 20, 2015 at 9:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Feb 20, 2015 at 1:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
An alternative is that we attempt to introduce
On Mon, Feb 23, 2015 at 11:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Feb 23, 2015 at 7:55 PM, Jonas Sicking jo...@sicking.cc wrote:
A lot websites accidentally enabled cross-origin requests with
cookies. Not realizing that that enabled attackers to make requests
that had
On Mon, Feb 23, 2015 at 7:55 PM, Jonas Sicking jo...@sicking.cc wrote:
A lot websites accidentally enabled cross-origin requests with
cookies. Not realizing that that enabled attackers to make requests
that had side-effects as well as read personal user data without user
permission.
In
On Sat, Feb 21, 2015 at 10:17 AM, Martin Thomson
martin.thom...@gmail.com wrote:
On 21 February 2015 at 20:43, Anne van Kesteren ann...@annevk.nl wrote:
High-byte of what? A URL is within ASCII range when it reaches the
server. This is the first time I hear of this.
Apparently, all sorts of
On 21 February 2015 at 20:43, Anne van Kesteren ann...@annevk.nl wrote:
High-byte of what? A URL is within ASCII range when it reaches the
server. This is the first time I hear of this.
Apparently, all sorts of muck floats around the Internet. When we did
HTTP/2 we were forced to accept that
On Thu, Feb 19, 2015 at 9:22 PM, Jonas Sicking jo...@sicking.cc wrote:
Would this be allowed for both requests with credentials and requests
without credentials? The security implications of the two are very
different.
Yes, but the latter requires the Access-Control-Allow-Credentials
header to
On Fri, Feb 20, 2015 at 9:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Feb 20, 2015 at 1:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
An alternative is that we attempt to introduce
Access-Control-Policy-Path again from 2008. The problems you raised
On Thu, Feb 19, 2015 at 4:49 AM, Dale Harvey d...@arandomurl.com wrote:
so presumably it is OK to set the Content-Type to text/plain
Thats not ok, but may explain my confusion, is Content-Type considered a
Custom Header that will always trigger a preflight? if so then none of the
caching will
Would this be allowed for both requests with credentials and requests
without credentials? The security implications of the two are very
different.
/ Jonas
On Thu, Feb 19, 2015 at 5:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
When the user agent is about to make its first preflight to an
On Thu, Feb 19, 2015 at 3:30 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 19, 2015 at 12:17 PM, Dale Harvey d...@arandomurl.com wrote:
With Couch / PouchDB we are working with an existing REST API wherein every
request is to a different url (which is unlikely to change), the
I think that POSTing JSON would probably expose to CSRF a lot of things
that work over HTTP but don't expect to be interacted with by web browsers
in that manner. That's why the recent JSON encoding for forms mandates
that it be same-origin only.
On Thu Feb 19 2015 at 12:23:48 PM Jonas Sicking
On 20 February 2015 at 00:29, Anne van Kesteren ann...@annevk.nl wrote:
Access-Control-Allow-Origin-Wide-Cache: [origin]
This has some pretty implications for server deployments that host
mutual distrustful applications. Now, these servers are already
pretty well hosed from other directions,
On 18 February 2015 at 06:31, Brad Hill hillb...@gmail.com wrote:
Some of the things that argue against /.well-known are:
1) Added latency of fetching the resource.
It's not available everywhere yet, but you could push it, based on the below.
2) Clients hammering servers for non-existent
Anne van Kesteren ann...@annevk.nl wrote:
Concerns raised by Monsur
https://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0260.html
and others before him are still valid.
When you have an HTTP API on another origin you effectively get a huge
performance penalty. Even with caching of
On Thu, Feb 19, 2015 at 11:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 19, 2015 at 11:43 AM, Brian Smith br...@briansmith.org wrote:
1. Preflight is only necessary for a subset of CORS requests.
Preflight is never done for GET or HEAD, and you can avoid preflight
for POST
On Thu, Feb 19, 2015 at 2:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 19, 2015 at 11:43 AM, Brian Smith br...@briansmith.org wrote:
1. Preflight is only necessary for a subset of CORS requests.
Preflight is never done for GET or HEAD, and you can avoid preflight
for POST
With Couch / PouchDB we are working with an existing REST API wherein every
request is to a different url (which is unlikely to change), the
performance impact is significant since most of the time is used up by
latency, the CORS preflight request essentially double the time it takes to
do
Dale Harvey d...@arandomurl.com wrote:
The REST api pretty much by design means a unique url per request
CouchDB has http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API,
which allows you to fetch or edit and create multiple documents at
once, with one HTTP request. CouchDB's documentation says
On Tue, Feb 17, 2015 at 8:43 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Anne van Kesteren wrote:
On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
Individual resources should not be able to declare policy for the whole
server, ...
With HSTS we gave up on
On Thu, Feb 19, 2015 at 11:43 AM, Brian Smith br...@briansmith.org wrote:
1. Preflight is only necessary for a subset of CORS requests.
Preflight is never done for GET or HEAD, and you can avoid preflight
for POST requests by making your API accept data in a format that
matches what HTML forms
What is it about PouchDB and CouchDB that causes them to require
preflight for all of these requests in the first place? What is
difficult about changing them to not require preflight for all of
these requests?
The REST api pretty much by design means a unique url per request, in this
case a
On Thu, Feb 19, 2015 at 12:17 PM, Dale Harvey d...@arandomurl.com wrote:
With Couch / PouchDB we are working with an existing REST API wherein every
request is to a different url (which is unlikely to change), the performance
impact is significant since most of the time is used up by latency,
On Thu, Feb 19, 2015 at 4:49 AM, Dale Harvey d...@arandomurl.com wrote:
so presumably it is OK to set the Content-Type to text/plain
Thats not ok, but may explain my confusion, is Content-Type considered a
Custom Header that will always trigger a preflight?
To be clear, my comment was about
Will take a look at the content-type on GET requests, thanks
I believe none of these require preflight unless a mistake is being
made (probably setting Content-Type on GET requests).
http://www.w3.org/TR/cors/#preflight-result-cache-0
If the cache is against the url, and we are sending
Dale Harvey d...@arandomurl.com wrote:
I believe none of these require preflight unless a mistake is being
made (probably setting Content-Type on GET requests).
http://www.w3.org/TR/cors/#preflight-result-cache-0
If the cache is against the url, and we are sending requests to different
The cache would be on a per requesting origin basis as per the headers
above. The Origin and Access-Control-Allow-Origin would not take part
in this exchange, to make it very clear what this is about.
I dont want to conflate what could be seperate proposals, but they seem
closely related, this
so presumably it is OK to set the Content-Type to text/plain
Thats not ok, but may explain my confusion, is Content-Type considered a
Custom Header that will always trigger a preflight? if so then none of the
caching will apply, CouchDB requires sending the appropriate content-type
I tried
When the user agent is about to make its first preflight to an origin
(timeout up to the user agent), it first makes a preflight that looks
like:
OPTIONS *
Access-Control-Request-Origin-Wide-Cache: [origin]
Access-Control-Request-Method: *
Access-Control-Request-Headers: *
If the
On Feb 19, 2015 3:33 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 19, 2015 at 12:17 PM, Dale Harvey d...@arandomurl.com wrote:
With Couch / PouchDB we are working with an existing REST API wherein
every
request is to a different url (which is unlikely to change), the
performance
If the cache is against the url, and we are sending requests to different
urls, wont
requests to different urls always trigger a preflight?
I just realised my mistake, GETS without custom headers should need to
trigger preflight requests, sorry
On 19 February 2015 at 13:31, Dale Harvey
On 19 Feb 2015, at 22:04, Martin Thomson martin.thom...@gmail.com wrote:
On 18 February 2015 at 06:31, Brad Hill hillb...@gmail.com wrote:
Some of the things that argue against /.well-known are:
1) Added latency of fetching the resource.
It's not available everywhere yet, but you could
* Jonas Sicking wrote:
We most likely can consider the content-type header as *not* custom.
I was one of the people way back when that pointed out that there's a
theoretical chance that allowing arbitrary content-type headers could
cause security issues. But it seems highly theoretical.
I suspect
On Thu, Feb 19, 2015 at 5:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
When the user agent is about to make its first preflight to an origin
(timeout up to the user agent), it first makes a preflight that looks
like:
OPTIONS *
Access-Control-Request-Origin-Wide-Cache: [origin]
* Martin Thomson wrote:
On 20 February 2015 at 00:29, Anne van Kesteren ann...@annevk.nl wrote:
Access-Control-Allow-Origin-Wide-Cache: [origin]
This has some pretty implications for server deployments that host
mutual distrustful applications. Now, these servers are already
pretty well hosed
On Thu, Feb 19, 2015 at 12:38 PM, Brad Hill hillb...@gmail.com wrote:
I think that POSTing JSON would probably expose to CSRF a lot of things that
work over HTTP but don't expect to be interacted with by web browsers in
that manner. That's why the recent JSON encoding for forms mandates that
* Martin Thomson wrote:
On 20 February 2015 at 11:39, Bjoern Hoehrmann derhoe...@gmx.net wrote:
The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`.
I missed that. In which case I'd point out that `OPTIONS *` is very
poorly supported. Some people (myself included) want it to
On 20 February 2015 at 11:39, Bjoern Hoehrmann derhoe...@gmx.net wrote:
The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`.
I missed that. In which case I'd point out that `OPTIONS *` is very
poorly supported. Some people (myself included) want it to die a
flaming death.
On Tue, Feb 17, 2015 at 2:43 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Anne van Kesteren wrote:
On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
Individual resources should not be able to declare policy for the whole
server, ...
With HSTS we gave up on
+1 to Anne's suggestion. The current design is pretty terrible for API
performance. I think a request to / with OPTIONS or something, with a
response that requires some server side logic (like return the random
number UA just sent) is pretty darn secure.
cheers
dev
On 17 February 2015 at 11:24,
Concerns raised by Monsur
https://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0260.html
and others before him are still valid.
When you have an HTTP API on another origin you effectively get a huge
performance penalty. Even with caching of preflights, as each fetch is
likely to go to a
On both this, and CSP pinning, I find myself getting nervous about adding
an increasing number of headers which, when sent by any resource, impact
the security posture and functioning of an entire origin. HSTS and HPKP
are somewhat special in that: they convey only a few bits of information.
are
* Anne van Kesteren wrote:
With the recent introduction of CSP pinning, I was wondering whether
something like CORS pinning would be feasible. A way for a server to
declare that it speaks CORS across an entire origin.
The CORS preflight in effect is a rather complicated way for the
server to
On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
Individual resources should not be able to declare policy for the whole
server, ...
With HSTS we gave up on that.
HTTP/1.1 rather has `OPTIONS *` for that, which would require a
new kind of preflight request. And if
* Anne van Kesteren wrote:
On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
Individual resources should not be able to declare policy for the whole
server, ...
With HSTS we gave up on that.
Well, HSTS essentially removes communication options, while the intent
of CORS
55 matches
Mail list logo
