-----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
