0

The situation is a bit more complex than the title suggests (but not much).

I'm working on a REST API that will have a few open / publicly available resources and a few with authentication. (The latter is currently BasicAuth, but may in the future become something else.)

Obviously, I'd like to have HTTPS for the authenticated resources. But should I also use it for the open ones?

I can't decide between:

  • Using HTTP means less overhead and less fiddling with certificates for both server and client
  • Using HTTPS means a more homogenous setup, plus it hides the content from being read during transport

Thoughts?

Antares42
  • 109
  • 3
  • 2
    How important is the data that you are sending back and forth? Is this personal information? Is it catchable on the cloud (sports scores for the latest game)? or requests for the weather or stocks (which, incidentally can contain personal information)? Why have you ruled out having both? –  Nov 23 '15 at 14:49
  • @MichaelT Not entirely sure how to define "important". The data on the public URLs would be, well, public and thus not secret. I didn't explicitly consider the mixed case, but my framework (JAX-RS and Jboss) would probably allow that by default, so I didn't think about it much. – Antares42 Nov 23 '15 at 14:55
  • Someone asking for information about the weather at a given location is more likely than not, there. Someone asking about stocks more than likely has those stocks. This sort of leaking of personal information is of great concern to some (and completely below the radar to others). –  Nov 23 '15 at 14:57
  • That is a very good point, and among my considerations for HTTPS. I don't think it applies here (this will be a database of academic projects), but then again, I don't get to decide how concerned my users should be about sort-of-publicly showing interest in my data. In other words, I'm leaning more and more towards definitely offering HTTPS on all services. The question is then, should I offer HTTP at all? – Antares42 Nov 23 '15 at 15:09
  • 1
    Reading [this sort-of-related](http://programmers.stackexchange.com/a/301026/167677) answer I'm starting to think that I'd want to use all HTTPS and no HTTP. There will be token and/or header-based auth stuff in the future (think rate limiting for the open endpoints), so I guess the safest option will be HTTPS-only...? – Antares42 Nov 23 '15 at 15:23
  • 2
    That is indeed a valid approach. The https only choice is one that many providers are making. –  Nov 23 '15 at 15:24

2 Answers2

3

Is it a problem if anyone else is able to read the data you're transmitting (sending and receiving)?

Is it a problem if data that you transmit might be altered in route?

If the answer to either question is "yes," then you should be using HTTPS.

Obviously if the data you're sending is trivial and/or available elsewhere, then HTTP is fine. But if the users are sending email addresses, passwords, etc. (even if it's only for your site), then consider HTTPS.

Mike Harris
  • 572
  • 3
  • 12
1

As a Information Security Analyst, the default answer is to go fully HTTPS (This might even be a good topic for the IS SE page.) The reason is pretty simple, your using HTTPS for you authenticated sources, at this point, you already have the complexity of using TLS, extending it to additional ports from a maintenance point is irrelevant.

Shane Andrie
  • 175
  • 5
  • Maintenance, yes, but performance and consumer convenience? – Antares42 Nov 23 '15 at 15:49
  • @Antares42 the first is a non-issue today ***unless*** you are dealing with certain high volume identical requests that need to move out to be cached in the cloud. –  Nov 23 '15 at 15:54
  • Your scale and complexity to make a performance hit, would mean the cost/maintenance piece is negligible. From a consumer convenience perspective, we already use TLS every day without impact, if your doing best practices (TLS 1.2/ 2048 minimum key / etc) no consumer would notice an issue. – Shane Andrie Nov 23 '15 at 15:57
  • Most consumers of web-services are competent enough to not really be bothered by using HTTPS instead of unsecured web-APIs. – kat0r Nov 23 '15 at 16:19