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?

Improve this question
6
  • 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?
    – user40980
    Nov 23, 2015 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, 2015 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).
    – user40980
    Nov 23, 2015 at 14:57
  • 1
    Reading this sort-of-related 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, 2015 at 15:23
  • 2
    That is indeed a valid approach. The https only choice is one that many providers are making.
    – user40980
    Nov 23, 2015 at 15:24

2 Answers 2

Reset to default
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.

Improve this answer
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.

Improve this answer
4
  • Maintenance, yes, but performance and consumer convenience?
    – Antares42
    Nov 23, 2015 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.
    – user40980
    Nov 23, 2015 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, 2015 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, 2015 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.