Use HTTPS Strict Transport Security. This will tell users' browsers: please, only connect to me over https. This defends against sslstrip and similar man-in-the-middle attacks.

Set the secure flag on all cookies. This will ensure that the cookies will only be sent over a https channel, never over an insecure http link.

Avoid third-party active content served over http. Don't load external active content over http. Make sure that any CSS, Javascript, widgets, analytics, or ads that you load from third-party sources are loaded over https.

Potentially better yet, you can consider making your own copy and serving these resources from your own server if possible, so you don't need to load them from a third-party source. In many cases you can avoid loading CSS, Javascript libraries, or widgets from third-party sources simply by storing a copy on your own server.

For analytics, note that Google Analytics does support https.

Ads are the hardest part. If you use ads, you may not have any choice but to accept third-party ads over http, which is a security risk. If you do, serve the ads in an iframe (do not use SCRIPT SRC to integrate the ads into your page).

It is OK to load images hosted on a third-party host as long as they are loaded over HTTPS (to avoid mixed-content warnings).

I think if you do these four things, you'll cover most of the issues. The rest are details that can be evaluated on a site-specific basis, but they are probably secondary in importance (in my opinion).

If you want to get fancy, you can look at certificate pinning and similar emerging technology, but starting with the above four is already a significant enough project.

If images are loaded over HTTPS from a third party, then is there any real security benefit to hosting them yourself? What security breach can occur with an image over HTTPS?
–
Justin CloudApr 9 '14 at 20:30

1

@JustinCloud, you are right. There's nothing wrong with loading images from third-party sites (if they are loaded over HTTPS). I will edit my answer accordingly -- thank you for catching that!
–
D.W.Apr 9 '14 at 21:19

User's Security

You are missing one extremely important thing: CSRF mitigation.

Be sure to fully understand the related problems. Tldr: in addition to the authorization token (e.g. session cookie), you need a challenge per action to identify if the action is intended by the user or unintended.

Show a hugehuge warning when users use weak passwords, or not accept it altogether.

Train users (perhaps via an arrow image on every page pointing to the green bar) to check whether your pages are loaded with HTTPS. If they ever use a browser that does not support HSTS, at least they would notice that HTTPS is missing.

Suppose that Alice is surfing the Web, and she visits Bob’s Web
site at http://www.bob.com. Bob wants to find out whether
Alice has visited Charlie’s Web site (http://www.charlie.
com).

First, Bob looks at Charlie’s site, and picks a file that any visitor
to the site will have seen. Let’s say Bob picks the file containing
Charlie’s corporate logo, at http://www.charlie.com/
logo.jpg. Bob is going to determine whether the logo file is in
Alice’s Web cache. If the file is in her cache, then she must have
visited Charlie’s Web site recently.

Bob writes a Java applet that implements his attack, and embeds
it in his home page. When Alice views the attack page, the
Java applet is automatically downloaded and run in Alice’s browser.
The applet measures the time required to access http://www.
charlie.com/logo.jpg on Alice’s machine, and reports this
time back to Bob. If the time is less than some threshold (say, 80
milliseconds), Bob concludes that Alice has been to Charlie’s site
recently; if it is greater than the threshold, he concludes that she has
not been to the site recently.