Since it's been requested that this question be rewritten:

Is SSL (or some other encryption equivalent) required in the below case? From a small local business website, is there any damage that an attacker can do with semi-sensitive customer information (e.g. the list of items below)?


I've started working on redesigning a client's website. They are a small business and their website has a very basic system setup. No one pays online, but items are reserved by filling out a form. As of now, this information is submitted without any security / encryption. The information includes:

  • name
  • phone number
  • address
  • email

That is about as sensitive as it gets, i.e., there is no credit card information, passwords, or anything like that.

Does this kind of information constitute some kind of security (e.g. SSL)? How sensitive does information need to be such that security is required? Is there an industry standard?

  • 2
    A a user of web sites, I would want those personal pieces of my information kept secure from people attacking a business to build lists of that sort of thing. As a small business owner, I would want my database of (potential) customers and their contact information kept secret not only to protect those people, but also to dissuade my competition from attempting to steal this from me. As a normal person on the web, I wouldn't think twice about encryption/clear, until I read about some site getting in trouble -- then I'd avoid that site.
    – mah
    Nov 22, 2013 at 17:11
  • @mah I agree with that. To protect their contact information is there any other measure than ssl? I know getting a certificate can be somewhat expensive and from a small business owner's perspective the ROI seems low.
    – souldzin
    Nov 22, 2013 at 17:31
  • 1
    There are always other ways to communicate (Java applet using a custom communication protocol, for example) but nothing as a standard "use this instead of SSL". Keep in mind also that SSL does not only encrypt the communication, it also helps the client be certain they're talking to the site they think they are, and not a man in the middle.
    – mah
    Nov 22, 2013 at 17:35
  • 1) There are free SSL certificates, and even normal paid certificates are relatively cheap. Get the cheapest certificate recognized by all relevant browsers. No need to get fancy. 2) Biggest issue with SSL is that older browsers need a distinct IP address per domain, which clashes with cheap virtual servers. 3) Alternative encryption methods, for example using javascript are significantly weaker since they can't protect against active attackers. They're also significantly more development effort, and thus most likely more expensive in practice. Nov 26, 2013 at 9:38

3 Answers 3


Reasons to use HTTPS:

Encryption: As @mah's comment says, HTTPS traffic is difficult to read and / or change by a man-in-the-middle.

Verification of Identity: An SSL certificate is proof to the user that the content being served is actually coming from the server it purports to be.

In other words, HTTPS not only encrypts the information but also tries to guarantee that the server that the user is talking to, is truly the server they think it is. If your client's site is HTTP, a competitor or other party could fake the web site entirely so that the user is really talking to some other website and it is easy to imagine ways to abuse the customer of a company you don't like with a web site you control. Man-in-the-middle is not even needed then. To me, this is a good reason to use HTTPS in your case.

If the attacker tried this with against an HTTPS site, the browser should raise an alarm. These days, those alarms are difficult for the web user to not notice.


Name, address, phone, and email are all Personally Identifiable Information (PII). Although it's not likely to be a regulated business, you should protect your client by encrypting this information in transit by SSL and also protecting it on the system.

Ask yourself how you'd want your information to be transmitted if you were a customer. Most would think encrypting those details would be a good thing, and may perhaps even assume you are doing it as a matter of common sense. Think of it as the golden rule of data - treat others' data how you would want your own to be treated.


The personal information such as names, email addresses, phone numbers, and mailing addresses are not private. This is information that is meant to be shared with others. SSL does not really protect information that is already publicly available in more accessible formats such as the phone book.

(However, you do need a good privacy policy when storing and using people's personal information, to assure your users why you need their personal information, and what you intend to use it for. This is mostly because some organizations have a history of selling their databases of personal information against the wishes of their clients. SSL does not help with this, however.)


  • Having a strong privacy policy does no good if you're choosing to transmit the data in the clear. Your policy, when followed, might say you won't intentionally release the information however if you don't encrypt the communication, the person sniffing the traffic might have a different view. As to "personal information is not private" -- perhaps yours isn't, but I keep my information private, giving it out only when I choose to. I have no legal recourse should those I give it to release it further perhaps, but that's a different matter.
    – mah
    Nov 22, 2013 at 17:38
  • The information may not technically be "private" (as it can be found in a phone book, etc.) but most of it, especially in combination with the other pieces, is considered PII and may be subject to regulation by law (current or near-future). Even if not, breach of the data (and the subsequent lawsuits - rest assured there will be some) could result in your company being the case that sets the legal precedent for new privacy laws.
    – Iszi
    Nov 22, 2013 at 20:31

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