1

I have found in one of the client side libraries that it is performing an AJAX call to an API and checking if response contains all of the following headers with corresponding values (as a security measure):

'content-type', 'application/json'
'content-type', 'charset=utf-8'
'X-Content-Type-Options', 'nosniff'
'content-disposition', 'attachment'
'X-Frame-Options', 'DENY'

If any header is not present, the library throws an exception. Is there a security reason to ever perform existence checks on HTTP headers?

Improve this question
10
  • "as a security measure" - are you sure it is a security measure? It seems like this would be a question for the library dev and not random people.
    – schroeder ♦
    Commented Oct 14, 2019 at 12:19
  • Yes, I am sure, it's an internal library and there is a document that says that it's a security measure, failing to explain why...
    – Ilya Chernomordik
    Commented Oct 14, 2019 at 12:23
  • 1
    @IlyaChernomordik Sounds more like "cargo cult" to me. If you can ask the developer of the library what it should secure against, perhaps he could give an insight. I personally consider it pointless, as the target it not a browser. None of these headers mean anything by themselves.
    – user163495
    Commented Oct 14, 2019 at 12:27
  • "internal" as in, someone in your company? If so, then you need to ask the dev, not us.
    – schroeder ♦
    Commented Oct 14, 2019 at 12:29
  • 1
    @schroeder if there are all too many possibilities I would like to hear about some at least as I fail to see how this code can improve security. Can't see how it is opinion based? There is either a known use case it can solve or there isnt?
    – Ilya Chernomordik
    Commented Oct 14, 2019 at 12:36

1 Answer 1

Reset to default
1

It depends on the header, and on what the library is designed to handle. Let me go through each header and explain if it would make sense or not:

Does specifying Content-Type make sense?

Yes and no. It's certainly nice for the server to tell us that the response is in JSON, but it is by no means a requirement. It would make sense to throw an exception if the Content-Type was something unexpected, such as application/xml. However, to throw an exception if the content type was not specified seems overly strict. It doesn't give any security benefit either, since the application has to ensure that the consumed JSON was parsed correctly.

Specifying the charset is a "nice to have", as well, but I would wager defaulting to UTF-8 if no charset was specified should be the norm. An exception because the charset was not explicitly defined is overkill.

Does specifying X-Content-Type-Options make sense?

The X-Content-Type-Options header is designed to tell browsers "Don't try to figure out what this is on your own. Just trust my Content-Type header. Your library is not a browser, it probably doesn't try to figure out what kind of content it receives based on whichever parser doesn't throw an error. The fact that the library throws an exception if this header is not present likely indicates that the behavior of "Just parse whatever you get as JSON" is hard-coded, so demanding a header that tells the library to behave how it already behaves is pointless.

Does specifying Content-Disposition make sense?

No. The idea of Content-Disposition: attachment is to kindly ask the browser to download and save a file, rather than to display it. This can be nice if you want the user to download a file (e.g. a video), rather than to display it.

In the context of a JSON response of an API, this makes no sense whatsoever. Forcing the API to instruct the browser to download a response instead of displaying it inline just makes debugging harder. It's pointless, it makes your life harder, and it has no security benefit whatsoever.

Does specifying X-Frame-Options make sense?

No. The idea of X-Frame-Options is to prevent clickjacking. An API response is not an interactive website, and it makes no sense for an API consumer to demand this header to be set.

So, what should I do?

Remove these checks, plain and simple. They don't add to security and reduce compatibility.

The only checks that might make sense is the Content-Type header, but even then I would only throw an exception if the content type is something other than application/json, meaning that the server bothered to check and is sending something that the library knows it can't parse.

Improve this answer
4
  • It actually seems to be useful to use X-Frame-Options in the response from the server (stackoverflow.com/questions/34044966/…), but the point here is why should the client validate, which I think it should not
    – Ilya Chernomordik
    Commented Oct 15, 2019 at 11:28
  • @IlyaChernomordik It's certainly not a downside for the server to send X-Frame-Options, but that doesn't mean that a library should throw an exception if this header is not set.
    – user163495
    Commented Oct 15, 2019 at 11:29
  • Well, thanks a lot for the answer, I really do think exactly the same that it all pointless and was just a misunderstanding on the way. I hate to have "security measures" in code that noone can understand or explain, usually they do not give any security. I will try to wait a bit more for other opinions and accept your answer if noone has a better suggestion :)
    – Ilya Chernomordik
    Commented Oct 15, 2019 at 11:34
  • @IlyaChernomordik In the case of security measures, there should always be a comment that explains what each security measure does. Even something short like // If the Content-Type is anything but "application/json", we stop parsing and throw an exception, as we expect the API response to be JSON.
    – user163495
    Commented Oct 15, 2019 at 11:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .