I see this question come up quite a bit in places like StackExchange, and most often the question seems to be posted by a developer who's not deeply experienced with using SSL certificates. If you're an experienced dev, you probably already realise that simply asking the question, "Does my site need SSL?" probably means that it does.
Here's an example situation I recently saw: Someone is developing a backend solution for a company that is saving "sensitive information," and that backend can only be accessed from two IP addresses. The client has requested SSL, but the developer isn't sure it's necessary.
Does that site need SSL? Here's a checklist to compare against:
- Will the users of this site be connecting and transferring this sensitive information over a wireless connection at any point in time? If this is the case, then yes, it needs SSL.
Developers need to make sure that clients understand the limitations of wireless encryption. Without getting technical, you should always assume wireless encryption doesn't work or is easily defeated.
- Are there legal issues involved with this sensitive data? If you are transmitting customer information in a client database with phone numbers, postal addresses, email addresses, login information - or even more seriously, credit card numbers - then you need SSL.
Ask yourself if you would trust a company who transmitted this same information of yours without SSL.
- Is the client worried about the financial or performance costs of SSL?
HTTPS is not such a burden on server resources as it once was, especially with computing power and VPS or cloud setups being so cheap these days. And in the situation described above, with a site only being used by a limited number of users at defined locations, it should be trivial to provide horsepower enough for the maximum number of users.
The truth is that if the client wants functionality that requires SSL, then they need to pay for SSL, even if that means more expensive servers or load balancers. That's simply the cost of doing business. The outlay for proper security is dwarfed by the potential consequences of not having it.
Here's where as a developer one needs to start thinking about legal protection. If the client refuses to pay for SSL but wants you to do the job, ensure that your working agreement legally indemnifies you from any of their bad business decisions.
If financial costs are truly an issue, self-signed certificates can be used for internal systems. The OpenSSL toolkit provides good resources for this.
In the case above, however, the client requested SSL but the developer was unsure if it was necessary. If the client asked for it and is paying for it, setting up SSL isn't an undue burden on any developer worth their salt, and as a developer no one really ever should be in the position where they're arguing for less security. If there's a problem later, it comes back to bite you. Cover your rear end.
TL;DR - If it's even a question, use SSL.