-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Brian,
On 2/7/15 12:21 PM, Brian wrote:
Tomcat brings a special filter that implements the CORS
specification. In this filter, the default list of allowed headers
is the following:
Origin Accept X-Requested-With Content-Type
Access-Control-Request-Method Access-Control-Request-Headers
I know that I can replace that list by using the filter parameter
cors.allowed.headers and specify my own list of headers. I know
that. But I have the following questions:
- When this filter was created, why was the list filled with this
-abritrarily- short list of headers? Why these headers and not
others? Why, for example, isn't the cache-control header in the
list? How was this list chosen?
The W3C CORS standard recommendation
(http://www.w3.org/TR/cors/#access-control-allow-headers-response-header)
does not specify which headers should be included by default in this
list. So, it's probably up to the implementer to determine that list.
The author probably wanted to cover the smallest number of low-risk
headers for a default configuration. As you've said, the default can
be overridden. This is a fairly new Filter in Tomcat, so there may
have been some oversights.
The spec mentions simple headers of which Cache-Control is one. I
haven't read the spec well enough -- nor the code at all -- to know if
those simple headers are included by default but not mentioned.
The cors.exposed.headers specifically mentions them but
cors.allowed.headers does not. I suspect this is accurate, and that
no simple headers are included by default. If you want to add
Cache-Control then you should probably add it yourself.
- If I want to define a more complete list, which headers should I
include? There are some many headers to think about!
Now you see why the original author might have had a hard time
determining the default list.
- Can I use a * instead of specifying a list? Is that something
that the CORS specs allows?
This kind of defeats the purpose of the tool in the first place,
doesn't it?
- I know that the CORS specs defined this kind of list, but. Why is
that necessary? Why can't we just accept any header in the
pre-flight OPTIONS step, instead of returning a 403 (Forbiden) if
at least one of the headers requested by the client is not in the
list of allowed headers?
You certainly /can/ do that, but then you remove a layer of security
that the tool is supposed to provide.
- Why isn't there an option in the filter to do something like
this:
response.setHeader(Access-Control-Allow-Headers,
request.getHeader(Access-Control-Request-Headers)?
This would accept anything the client sent (which, of course, is what
you're asking about). Custom headers are a potential attack vector
and part of the reason that header white-listing is a part of the CORS
spec.
I'm puzzled. One of the users of my API sent the cache-control
header in the in the Access-Control-Request-Headers list during
the pre-flight step, and received an HTTP 403 error status. I can
add this header to the list (using the cors.allowed.headers
filter parameter). But what about next time some client sends
another header that is not in the list?
It sounds like you need to listen to to the needs of your customers
and adapt to them. You can either say sure, we'll white-list that
header or sorry, you'll have to remove that header from your request
because we see it as a security issue.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJU2MlHAAoJEBzwKT+lPKRYmxUQAK+cIucZ3jodP5wBvZugLz0m
iO2jDNDVz1KVJwDqsmtOaXQSFuGOsguUkyhbSW0RY4WMAbh4YellXDaXCC6zw02Q
vKzPJewvOyvmfN7Jztk2vmqfu0+ETFW6aVfWFz+azwUdzKv06Bs+rOlKgvbrtrtN
+hBqkFpZTMjDA77oc2i93fqv3GX8+Qy+XcaE0tMnULxcsLSoQzVJ6x03XyCvEpMX
v8SLWo12mUYio7VNBY56CeqxG+hCE9vY1hBVjzBM9kEzXe/YM/iOJAiocoScKcUn
8I1LA6kyCXYZM3ubYfaUV/jS0ebGXkeOyePuX1js1YC9vdgapzckwXNg1flUYs7i
9pbetj0n9E590eDaz3j6VaTchWf+RYL92CejU51g9/lvGN4whhAdFmehlV+TNJy/
gW95q2uY7SiU2ORepMKWI9zSQwFGDl+ve80jhupB4fg/xjk/cioe/VJQuazReyOj
JugpKH0Z3XjPXV5V2DneucvEhYyVtUqMqtTh7FPrZQL4xgGLslSDZSJHb2EDnyHt
7QqGU+2jhW5X0oxY6iFVBYgv2OX++ulAUcr14KH6vXfHLl4e8uCq0EuS9zXj29Ox
+bi3SBu3z62cLLV/gefzMjH3hmw+a0+f5/+xKc48aKADwat1W1051GjzWr+ErKOF
h1XH5OossOmsBCChwQcs
=Ok7B
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
