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?

Jeff Ferland
  • 38,170
  • 9
  • 94
  • 172
Ilya Chernomordik
  • 2,257
  • 1
  • 22
  • 36
  • "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 Oct 14 '19 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 Oct 14 '19 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. –  Oct 14 '19 at 12:27
  • "internal" as in, someone in your company? If so, then you need to ask the dev, not us. – schroeder Oct 14 '19 at 12:29
  • I know, I think the same, but noone can come up with a better idea of why apart from this document and noone knows who and why wrote it now :) Typical problem for large organization, but the fact is there is code and noone can explain why, that's why I am asking in here if maybe there is something I am missing – Ilya Chernomordik Oct 14 '19 at 12:29
  • There are far too many possibilities for why one would want to do this. We do not know the API or what the library is for. – schroeder Oct 14 '19 at 12:31
  • The library queries data from another server (a json object) and then renders som GUI represenation of that object (let's say {firstname: "A", lastname: "B"} is a response and the library has a component that can be rendered nicely for that json structure) – Ilya Chernomordik Oct 14 '19 at 12:33
  • 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 Oct 14 '19 at 12:36
  • I also don't see how this question is opinion-based. In my opinion, asking the negative "Is the absence of these headers for an API a security risk?" is on-topic. –  Oct 14 '19 at 12:51
  • Reopned with some edits. I think this is worthy of addressing whether an example like this is cargo culting without having to seek the explanation of the developers of the code in question. Feels similar in nature to https://security.stackexchange.com/questions/131106/is-there-any-reason-to-disable-paste-password-on-login/131107#131107 but worthy of its own discussion. – Jeff Ferland Oct 14 '19 at 23:55

1 Answers1

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.

  • It actually seems to be useful to use X-Frame-Options in the response from the server (https://stackoverflow.com/questions/34044966/is-it-meaningful-to-add-x-frame-options-in-an-restful-api), but the point here is why should the client validate, which I think it should not – Ilya Chernomordik Oct 15 '19 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. –  Oct 15 '19 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 Oct 15 '19 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.` –  Oct 15 '19 at 11:36