I saw that some e-commerce scripts can also run without ssl, but everyone recommends to activate it to protect sensitive data.

I just saw a site that has an e-shop link, if i click it my browser says that the security certificate is not reliable, and in fact if i click on "continue to the site" it switches to http.

Is it compulsory to activate ssl on a shop?


If you don't use HTTPS, but plain HTTP, then:

  • You will get hacked; credit card numbers will be stolen while in transit, and customers will sue you into oblivion.
  • You would be hacked anyway at some point, that's the lot of Web sites. Even if the hacker entered by some other way, post-mortem analysis will show the lack of SSL, and this will look real bad.
  • You will lose customers. Many potential customers won't enter their credit card number, for lack of the reassuring padlock picture; they will instead shop at a competitor's Web site.

So you are not mandated by Law to use HTTPS, but if you do not, your business will fail. Open business competition is quite akin to Darwinian selection: the weak dies.

Edit: @XzKto's comment shows that I have not been completely clear: the SSL bit is needed for the actual transaction, when banking values (e.g. credit card numbers) travel over the Internet. That's the one I am talking about. If the site records payment details (so that you can come back and buy again without reentering the credit card number), then the "buy it now" button must also be SSL-protected (to avoid an attacker "clicking" on it in your name). The rest of the site needs not necessarily be SSL-protected, although site-wide SSL is still often a good idea (it is much simpler than trying to work out which parts of the site must be protected, and which parts can be left out).

|improve this answer|||||
  • 8
    Maybe I'm a strange customer, but I have no problem with buying from sites that don't use SSL, but use external payment system. Even more, I would rather buy from a site that doesn't use SSL but uses external payment then from a little-known site that uses SSL and some internal payment system. Also, I don't think that not using SSL has anything to do with hacking the site. SSL doesn't protect the server, it protects customers. Maybe change "You will get hacked" to "Customers may get hacked"? Anyway no downvote, but the answer is close-minded, imho. – XzKto Apr 5 '13 at 13:24
  • This answer also doesn't take into account that you have to put more than you need to under SSL for your users, so pick-and-choosing pages becomes even more complex. As long as the submission of sensitive information is through HTTPS, the page it's on doesn't need to be - except that the browser will tell the user that you're not on a secured site. – Izkata Apr 5 '13 at 18:14
  • Thanks, is there some law that can be applied in case of stolen data due to unsecure payments? – Harlandraka Apr 29 '13 at 16:20
  • @Harlandraka: That would depend on many things - jurisdiction of the shopper, your jurisdiction, and most importantly, how good your and the shopper's respective lawyers are ;) In other words, "maybe." – Piskvor left the building May 8 '13 at 13:15
  • @Piskvor Thanks. do you know if prestashop's PayPal checkout redirects to paypal (so i don't need https) or uses PayPal API on the server (so i have to enable https)? – Harlandraka May 11 '13 at 11:11

I'll go ahead and say it. Yes it is compulsory to use SSL with an e-commerce site.

While nobody is really following you with an axe to decapitate you if you don't use SSL, using SSL for sites like e-commerce is crucial. So it is compulsory in the sense that you'll get into a lot of troubles when your customers' accounts are stolen or when somebody starts to manipulate with your customer's sessions.

Why should you use SSL with an e-commerce website?

  1. Protect your customers' login information.
  2. Protect your customers' sessions from being hijacked (cookies will be sent in plaintext).
  3. Protecting your customers from being taken to a whole different fake website (DNS spoofing).
|improve this answer|||||
  • 2
    You'll have to perjure yourself while taking the PCI SAQ-D self assessment if you don't. And if anything goes remiss, you'll be facing fines from your credit card processor along with having your ability to process credit cards being suspended. – Fiasco Labs May 8 '13 at 7:16

If you don't have account information and handle credit card information through a payment gateway, then no, it isn't compulsory. It is entirely possible to run an e-commerce site safely without HTTPS if you know what you are doing and jump through a bunch of very special hoops. (No username/password, Process payment offsite through a payment gateway or Paypal, use Order #s for tracking, etc). In this case, all you'd be doing is having people put together a list of items they way and sending that list (or the total) to a secure service to deal with the sensitive bits and they send back a token as a receipt.

That said, why would you want to have the headaches? People are far less likely to trust your site even if you set it up correctly to avoid all the possible pitfalls of not having HTTPS. It's much easier to do with HTTPS and well worth either using a self signed or cheap SSL cert. You can get SSL certs as cheap as $60 for two years (and maybe cheaper). There is really no good reason not to use SSL(HTTPS).

Also note that to handle credit card details, it is generally compulsive to use SSL for the exchange as part of the merchant services agreement. More specifically, if you touch, handle, work with or store payment card information (PCI), then the merchant services agreement will almost certainly require that you follow PCI-DSS. This is a big part of why even storefronts using SSL may often opt to use a payment gateway to handle the credit card data so they don't have to worry about the finer points of PCI-DSS.

|improve this answer|||||

It's not "compulsory" -- nobody is forcing the sites.

But it is advisable. While the homepage/etc1 need not be on an HTTPS connection, all the pages that have forms and those which show sensitive data should be. For example, it's perfectly OK for a site to let you shop on HTTP, but will redirect you to HTTPS for checkout.

Try to keep HTTPS for all pages after a log in to prevent session hijacking as well. It is best to keep your HTTPS pages on a separate domain (http://example.com but https://shop.example.com) for this same reason.

Otherwise, just encrypt all the things. It's not too hard.

Without an HTTPS connection, all the details you enter into the form will be visible to an attacker.

1. There may be some benefits of doing this, though. It could prevent a man in the middle from modifying the secure links to point to their own, HTTP sites.

|improve this answer|||||
  • Why is this downvoted? Nothing wrong with it. +1 – user10211 Apr 5 '13 at 11:21
  • 1
    @TerryChia "While the homepage/etc need not be on an HTTPS connection". At least the Secure flag should be mentioned to make that statement some-how okay. – Adi Apr 5 '13 at 11:25
  • @Adnan: What's wrong with that? What harm is there of having a homepage on HTTP? As long as all forms/pages with sensitive info are on HTTP, there's nothing an MITM attack can do on a homepage. – Manishearth Apr 5 '13 at 11:26
  • Never mind, I got it. Edited in. – Manishearth Apr 5 '13 at 11:28
  • @Manishearth Downvote reversed. Take a look at #2 in my answer. – Adi Apr 5 '13 at 11:31

No, it's not compulsory, but you have to be extremely careful if you don't.

HTTPS can stop man in the middle attacks, which HTTP is very vulnerable to.

However, HTTPS carries a processor (and hence speed) overhead. HTTPS causes out-of-session data to not be cached and hence can have re-download content with each visit. It also stops you from using (or makes it much harder to use) content delivery networks.

So lots of sites try to get by without it, but it's a dangerous line as mixing HTTP and HTTPS is very risky - you have to use HTTPS authentication cookies, which means that your user will only be logged on when visiting HTTPS pages.

If you ever let an HTTPS authentication cookie be sent to an HTTP page then you've left open an easy attack route for hackers.

What many sites do is this:

  • Anonymous users can browse the e-shop, and build up a shopping basket
  • Once they proceed to checkout or log in they're switched to the (slower) HTTPS secure version.
  • They're given an HTTPS-only authentication cookie, and sometimes an HTTP cookie too with just the username.

This is what Amazon does - cookies holding your username and basket are not secure and can be easily nicked, but you have to sign in to the HTTPS area (or have a valid, unexpired HTTPS cookie) to buy anything or view your account.

That's a fine line though, you need good (highly security aware) developers and support staff. For most sites it's a lot easier and lower risk to just HTTPS everything.

2016 Update

I don't think my answer above is right any more. HTTPS is now compulsory, for a couple of reasons:

  • HTTP/2 means secure sites are often significantly faster.
  • Various advanced features are HTTPS only, such as service workers.
  • Google Chrome (and probably other browsers soon) are increasingly flagging sites that don't use HTTPS. By 2017, rather than just the green padlock, sites without HTTPS will display a warning:

Eventual depiction of all non secure connection in Chrome

|improve this answer|||||
  • Unless you're Google-sized, Moore's Law has obliterated the "speed overhead" problem sometime during the last decade. And if you are Google-sized, there are also ways to overcome the "speed" issue. TL;DR: "HTTPS is slow" is just an excuse nowadays. – Piskvor left the building May 8 '13 at 13:18
  • @Piskvor I wish you were correct, but my company has customers on Windows 2000, IE6, decrepit hardware and sub-dial-up connections. They moan about speed when they have to re-download all the JS, CSS and images on just two parallel HTTP connections with every SSL session. Moore's law can safely be relied on to get an idea of the power your attackers can lay their hands on, but your actual users? They might be on any old junk. – Keith May 8 '13 at 13:54
  • @Piskvor in addition even if encrypting the outgoing SSL content only adds 15% workload to your server that could be the difference between 85% of capacity and an overloaded server. – Keith May 8 '13 at 13:56

It is not compulsory and things will work even with http but it is not recommended.

By using https you make sure that the communication between you and you clients that may contain their credit card details and order details are encrypted and cannot be seen by a third party running a packet sniffer.

Let us say you do not use https:

  1. The credit card details and any other information may be compromised by using simple packet capturing.
  2. It will be very easy to do an MITM attack. This may result in corruption of important data like payment details or order details without the knowledge of the two communicating parties
  3. You are doing a business. If your counterparts have this feature , you have to implement this feature or you will lose customers.
|improve this answer|||||

While a practice that should definitely be followed whenever transmitting sensitive data (e.g. authentication credentials), using HTTPS is compulsory only when the Payment Card Industry Data Security Standard (PCI-DSS) is involved.

Is the e-commerce site storing, processing or transmitting account data? If yes, then it must comply with PCI-DSS.

PCI-DSS v2.0 clearly states:

4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.

Note: account data includes Primary Account Number (PAN), Cardholder Name, Expiration Date, Service Code, Full magnetic stripe data or equivalent on a chip, CAV2/CVC2/CVV2/CID, PINs/PIN blocks

|improve this answer|||||

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