Re: [CSP2] Large CSP headers

Hi Ben,

You will have to talk to the site operators and they will have to agree
that it's a good idea from a security perspective.

That all being said, this CSP is not going to protect against XSS with
'unsave-inline' and data: in the script-src directive. (There's more and
https://csp-evaluator.withgoogle.com/ will tell you.)

If they think their CSP is a great idea anyway, you might be able to
convince them to do User-Agent sniffing and not send browser-specific
headers for known client libraries (curl, python-request, whatever).
Might not be fun to maintain, but potentially worth the bandwidth
savings on their end as well as yours.


Hope this helps,
Frederik




Am 03.12.19 um 22:48 schrieb Ben:
> Good afternoon,
> 
> I'm trying to make a number of API requests to an endpoint that has
> excessively large CSP headers in the replies, and this seems like the
> best place to ask about what to do.
> 
> In practice I'm going to be making a lot of API calls, and CSP headers
> have become a bandwidth issue.
> 
> For example:
> $ curl --http1.1 -Lis https://api.itbit.com/v1/markets/XBTUSD/ticker | wc -c
> 4474
> 
> That reply only has a body-length of 428, and the vast majority of the
> rest are CSP headers.
> 
> HTTP2 doesn't help much, because api.itbit.com <http://api.itbit.com>
> marks all header fields as sensitive, so they skip the hpack table:
> $ nghttp  -v --multiply=2 https://api.itbit.com/v1/markets/XBTUSD/ticker
> | grep "recv HEADERS frame"
> [  0.436] recv HEADERS frame <length=2925, flags=0x04, stream_id=13>
> [  0.437] recv HEADERS frame <length=2842, flags=0x04, stream_id=15>
> 
> Is there a way to signal that the request is not coming from a browser
> so these headers may be suppressed or at least reduced?
> 
> Thanks a lot,
> 
> --Ben

Received on Friday, 6 December 2019 13:20:01 UTC