Minimal web security recommendations

For many years now, I have made an effort to contact owners of unsecure web sites and attempt to persuade them to fix the sites.  Lately as I have become increasingly involved with the Personal Clouds and Vendor Relationship Management communities, I have found many unsecure web sites within that community.  These communities are relatively new, fast growing and potentially transformative of Internet commerce and culture at large, so it’s important that security does not become a choke point for growth.  It is also my contention that the consolidation of one’s information into a personal cloud results in greater risk and therefore requires consistently strong and effective security design.  With this in mind, I offer my minimal list of requirements for any non-trivial web site.

Transport Security

Make sure the site passes the tests at Qualsys SSL Labs.  The test is point-and-shoot but as you will find out from that site, SSL itself is broken.  The recommended settings are to use a somewhat vulnerable cipher because the alternatives are to allow a more broken cipher or the BEAST attack. There is no unbroken cipher to use – basically because nobody has bothered to implement TLS 1.1.  So at some point when these get patched, the recommendations will change.  The implication is that to be secure requires an ongoing security program and someone whose job it is to stay up to date on such things and reconfigure or apply patches accordingly.

Render all pages and assets over SSL/TLS.  Now that all browsers and HTTP servers have SSL session handling so the key is not renegotiated on each request, there’s no benefit in serving anything over http anymore.  Even content distribution networks can now use SSL/TLS at the network edge to serve static assets such as images.  Once your site is all SSL/TLS you can then enable Strict Transport Security which tells browsers “if any element on the site is *ever* served over HTTP instead of HTTPS there’s a problem.”  Make sure the site also works with HTTPS Everywhere.

 Application design and configuration

Make sure your site does not have any of the OWASP Top 10 vulnerabilities.  This does not guarantee the site is secure but it’s a good start.  The bad guys use the OWASP Top 10 as an attack plan so in general untargeted scanning type attacks are often based on these vulnerabilities.  If you have them, you *will* get hacked.

Of the various OWASP Top 10 items, password management and account recovery are broken so badly and so often, they deserve special focus. All those breaches you heard about in the news where passwords were stolen or accounts taken over (LinkedIn, Sony, Apple, Amazon, etc.) would have been non-events had those vendors bothered to do proper password management and account recovery.


When I first wrote the Hardening WebSphere MQ Security presentation for the IMPACT conference back in 2007, the first feedback I received was to provide a checklist.  But checklists are dangerous because people print or save them and then never update them, and also because they are necessarily incomplete.  This article is one such incomplete checklist and has the potential to do harm rather than good if used improperly.  However, the state of the Personal Clouds and VRM web sites that I have surveyed recently is such that it would be hard to make things worse.

To be sure, there are several sites that appear to have followed all of these recommendations and which I trust with my personal information.  But at the same time there are far too many sites purporting to be worthy of your business, asking you to trust them with your personal data, and yet implemented with massively broken security.  Because most casual users would not know how to tell the difference, a significant breach on one of these sites will tar all of us with the same brush.  So we in the community need to be our own first and best critics.  We need to understand the basics of secure web application design, set a bar for quality, and then hold our communities accountable to at least that minimal standard.

This, then, is my stake in the ground.  It isn’t intended to be final or complete, but rather a rallying point from which we can decide how our communities of interest and professional associations will address these issues.  In particular, I would expect PDEC to formalize some security recommendation because the “E” stands for “Ecosystem” in recognition of the interdependence and impact members have on one another.  Similarly, I offer this to the Respect Network as a starting point for a formal recommended baseline for members.


  1. T.Rob: As Managing Director of the Respect Network, I want to thank and applaud you for proposing this security baseline. We have much more work to do to establish the full security and privacy requirements for Respect Network members, but this post points everyone in the right direction.



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.