Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know that protecting all pages with SSL will slow down the website and add overhead to the server resources.

I also see many other websites only protecting their login and registration page, which I also want to do on my server running apache.

Why is it considered bad practice to only protect only pages where the user's password is entered instead of the whole site?

Also, instead of using something like, should I maybe change to https in this way:

share|improve this question
"I know that protecting all pages with SSL will slow down the website and add overhead to the server resources." <-- do you really know this? Technically speaking, it's true - TLS adds a minuscule bit of overhead, but today's CPUs perform all of the cryptographic operations in hardware, making resource usage not even worth considering. Honestly, just put your entire site under TLS. It will be much easier to manage - there is really no good reason to not do this. – EEAA Aug 31 '13 at 16:05
Tne short answer is this: In order for people to still be logged in when they go to pages that aren't protected by SSL, they'll have to send something functionally equivalent to their login credentials in the clear. – David Schwartz Aug 31 '13 at 20:36
As I understand it, the reason for using a "secure" domain is to protect certain cookies from being sent over an insecure connection, though there are better ways to do that. – Falcon Momot Sep 1 '13 at 6:53
The main reason why I dont want to secure the whole site is: I often have around 10k visitors/day, but 90%+ of those never login on the site. They only spend time browsing ads on my index page. Yeah it would be much easier for me to just run all pages under ssl, but consider that so little people actually login I dont want to. – user2722667 Sep 1 '13 at 19:46
You haven't really explained where you got this 'bad practice' idea from. This shouldn't be taken as gospel and I (along with EEAA it seems) don't necessarily agree with that statement. Considering this makes up a big part of your question it makes sense to address it. – Drew Khoury Sep 2 '13 at 0:54

Cookie security is the main thing that I'd point to for your approach.

A user that logs in on your secure login page gets a cookie for their session, right? That cookie's then being transmitted in plain text for someone watching the wire (Firesheep) to intercept and steal the session.

There is additional overhead in terms of negotiation time and CPU load from SSL, but it's rather minimal. If there's anything sensitive going on on your site, just use SSL everywhere.

See also: this question

share|improve this answer

I know that protecting all pages with SSL will slow down the website and add overhead to the server resources.

This is true. You shouldn't just throw on SSL on a whim. You should make an informed decision about it. While SSL does introduce security benefits, it does come at the cost of performance. It's important to remember that you can always throw technology solutions at a performance problem so I would make sure you're happy with your security first, then try and deal with any performance issues you may come across.

The main takeaway is, if SSL solves your security concerns go ahead and use it.

Why is it considered bad practice to only protect only pages where the user's password is entered instead of the whole site?

It's not. Well not necessarily. You really need to have a look at what data you're trying to protect, and what at attacks you're trying to prevent.

Common areas to consider:

  • Is there sensitive data on your whole site, or just on a finite set of pages?
  • Is it going to be easy to implement SSL on some pages, rather than all pages?
  • Are you dealing with any credit card data
  • Do you have users that log into your site & member pages with private data
  • Do you capture data through forms, what sort of data is it?

Sometimes you may only want to secure parts of your website, such as a login page and any member pages. The public facing parts of your website may not require SSL and making them HTTP could give you considerable performance benefits.

Some people implement SSL on their whole site because it simplifies things.

Of course implementing SSL can be tricky, and sometimes the effort in trying to have SSL on one page but not the other can mean considerably more work. SSL on your whole site helps future proof it, cuts down on developer complexly, can avoid bugs and error messages to users (or worse still accidentally exposing sensitive data over HTTP).

Also, instead of using something like, should I maybe change to https in this way:

There are many ways to implement a login (and security) with PHP but you haven't really gone into enough detail here to safely comment. You should first outline what you're trying to achieve, then give an overview of how you're going to go about it, and then you can start to consider the pros and cons of alternatives.

share|improve this answer
Thanks for a very good answer, got a lot explained! Well on my website users can register to upload ads. So I only need to SSL secure the login page + register page. The data that they fill in during a registration is then hidden, I only use that data to confirm their identity. Here is why I dont want to secure the whole site: I can have up to 10k visitors/day, but almost 90%+ of those never login. They only spend time on the index page, browsing ads. So to secure the whole site would not be the best way for me. Off topic: Should I secure 1-2 pages with SSL using mod_rewrite? – user2722667 Sep 1 '13 at 19:40
Per Day metrics don't really make much sense, how many users (max) do you have concurrently? Your stats suggest you may have 7 per second which isn't very much. You have to make the decision as to if you want SSL on your whole site or not, there's not much point in someone else deciding for you. mod_rewrite can be used to redirect users so I imagine you'll use that as part of your solution. – Drew Khoury Sep 2 '13 at 0:51

SSL incurs quite a bit of extra processing time. For low bandwidth sites, the extra processing required by SSL is not really noticable. But for sites with heavy traffic like Facebook, Twitter and Flickr the load caused by SSL is heavy enough that they would have to use didicated SSL encoding/decoding hardware.

So basically yes, it makes sense to minimize the number of pages using SSL. That is why you often see banking sites only protect the actual account pages via https. The home/landing page is usually plain old http.

On the other hand, unless you really are a site like Twitter or Facebook or Gmail, worrying about this is a bit of a premature optimization. First do it simple if you can. Be aware of this issue and be aware of upgrade strategies when your site finally get heavy traffic.

My boss has a saying: this is a happy problem to have. First solve the sad problem of not having enough users then you'd be happy to have a problem that requires you to refactor your architecture.

share|improve this answer
SSL is no longer a significant overhead. See this answer on Webmasters for the results of the Google study on adding SSL everywhere. Key quote: In order to do this we had to deploy no additional machines and no special hardware. – Ladadadada Jan 20 '14 at 12:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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