A few other suggestions
This is a nice, and worthy, article - here are a few other things to watch for, some more and some less esoteric - that commonly crop up even in some otherwise well-written web applications.
Use the httponly cookie flag in addition to the secure flag. This flag, supported by most newer browsers (and ignored by most that don't), prevents cookies from being read by client-side javascript, the commonest way cookies are stolen (via XSS). (Obviously this depends upon your application not accessing cookies via javascript)
Disable HTTP TRACE on your webserver. HTTP TRACE returns the headers sent by the client in the request made to the webserver, and can be used in conjunction with XMLHttpRequest to obtain cookies even when httponly is enabled
Make sure you annul on the webserver *and* in the client the cookie when the user logs out. The same cookie (and sessionID) should never be used for more than one actual session, and the client should forget about it when it logs off. It's quite common to encounter web applications that don't do this, leading to the same session being recycled over and over and over again for successive logins from the same client. Stolen the user's session? Great. You've stolen seven.
Always ensure you only accept cookies issued by your application (ie. cookies marked as issued within whatever internal array or database table you use to store your list of valid sessions), and not cookies used before - some web applications accept anything with a valid number/pattern of characters, leading to an attack known as 'session fixation' if an attacker can set another user's cookie to a value known to him/her (eg. via XSS) who then subsequently logs in (giving the attacker a free session to use)
If your web framework requires you to incorporate code into each page you write to perform authorization and entitlement checks, MAKE SURE YOU DO, and centralise it wherever possible. Ensure you check both for a valid session and correct level of entitlement before you do any processing, particularly with POST requests. it's quite common to encounter applications that won't let limited users see the administrator parts of a site, but which accept correctly-formed administrative POST requests from limited users.
Use session management frameworks wherever you can, but /do/ be careful. Certain session management frameworks (like classic ASP) are antiquated and vulnerable (in ASP's instance to the session fixation attack mentioned above).
Ensure you use some form of transient authentication (eg. hidden form fields containing random values) on form posts to protect against CSRF attacks in which a third party submits a request (eg. a GET request in an img tag, or a POST request using XMLHttpRequest) to your website which automatically has cookies sent by the client - if a third party can do this (and in particular if your forms are submittable via GET and POST), an attacker may be able to ride your users sessions in a type of attack known as CSRF (or Cross-Site Request Forgery).
Lastly, but probably-should-come-firstly, make sure you educate your developers well. It's scarily common to encounter developers with big titles in important places who write fantastic functional code that's riddled with security holes. Get a good book on web application security (the web app hacker's handbook is my choice) and buy each of your devs a copy. Give them some time to read it - any developer worth their salt will be writing code that's miles more secure in no time.
Here endeth the lesson.