Occasionally, someone who is learning about security will ask insightful questions like "how long should passwords be?" or "how long should it be before a user is logged out for inactivity?" The correct answer, of course, is "it depends" followed by a smoke bomb and a disappearing act. If, however, you are cornered with a question like this, I think there are some reasonable guidelines everyone can agree on.
There are things you can get 100% right (like eliminating cross-site scripting) and there are some things that you get for free (like using a strong session ID token from a framework). But, there can be big tradeoffs in performance or usability for certain security mechanisms. The appropriate tradeoff varies with the risk profile of the site. Let's take a look at a few example security requirements, viewed through the light of two site risk profiles.
Weak: Something with no financial or private data. Forums, wikis, twitter, etc.
Strong: Anything with financial or private data. Banks, webmail, web hosting accounts, etc.
Is this too coarse to describe every site in the world? Yes, but it's a start.
Use of SSL
Weak: SSL is optional for everything but the login page (and the form it's served on).
Strong: HTTP redirects to HTTPS. SSL only.
Account Lockout
Weak: Either no brute force detection or basic request rate throttling.
Strong: Time-based lockout with increasing durations (5 minutes after 5 bad attempts, 10 minutes after 10 bad attempts, 20 minutes after 15 bad attempts, etc).
Session Timeout
Weak: A few weeks. Seriously! Look at GMail.
Strong: After ten minutes of inactivity, and no longer than a few hours, even with activity.
Password Strength
Weak: Six characters, and your password cannot be "password" (seriously)
Strong: At least eight characters, at least three character sets (upper, lower, numeric, special)
Password Reset
Weak: Email-based reset.
Strong: Email plus secret question/answer based reset.
Page Caching
Weak: All pages can be locally cached
Strong: No pages are locally cached
Username Enumeration
Weak: After a failed login, tell the user if the username they entered is valid.
Strong: After a failed login (or successful password reset, etc), do not disclose if the username the use user entered is valid.
Your requirements may vary, but I think this covers some of the common policy-based ones. Wouldn't it be a happier web application security world if everyone followed these guidelines?