Secure Web Authoring Best Practices

Editor's Draft 14 May 2008

$Revision: 1.1 $ $Date: 2008/05/14 14:19:18 $

This version:
Latest version:
Thomas Roessler, W3C
Anil Saldhana, RedHat


This specification defines security good practices for Web Site authors.

Status of this Document

This document is an editors' copy that has no official standing.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at

The Web Security Context Working Group is publishing this document to provide a basis for initial review of and commentary on its work. The Working Group had taken an inclusive approach toward publishing various technical proposals in its First Public Working Draft. The Working Group has since decided to adopt a two-phase approach, and expects to take an initial set of proposals to Last Call in or around June 2008. Material that the Working Group does not expect to include with that Last Call has been moved into appendices. No claims as to the efficacy of usability-related material are made.

To facilitate access to relevant background, various sections of this document are annotated with references to input documents that are available from the Working Group's Wiki, and to pertinent issues that the group is tracking. The documents in the wiki include background, motivation, and usability concerns on the proposals that reference them. They provide important context for understanding the potential utility of the proposals.

This document was developed by the Web Security Context Working Group. The Working Group expects to advance this Working Draft to Recommendation Status.

Please send comments about this document to (with public archive). For comments to be most useful, please follow these guidelines for writing useful issues.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1 Overview
2 Best Practices
    2.1 Do not use security indicator images to suggest trustworthiness
    2.2 Use TLS for Login Pages
    2.3 Use TLS Consistently across the web site
    2.4 Redirects between Pages with Different Security Levels
    2.5 Security Experience Across Devices
    2.6 Good Practices for the Creation of Audio Logotypes
3 Security Considerations
4 Acknowledgments
5 References

1 Overview

2 Best Practices

2.1 Do not use security indicator images to suggest trustworthiness

Web content MUST NOT use visual representations of Web user agent security indicators to suggest trustworthiness.

Renderings of Web user agent trust indicators (e.g., copies of common padlock icons) are occasionally used as part of a messaging that tries to suggest trustworthiness to users. While these indicators are often surprisingly successful messaging tools, that success comes at a price: It trains users to give indicators in content precedence over indicators in chrome. This lessens the effectiveness of any chrome indicators for the sites that re-use them as part of their content; it also has a broader training effect that can be capitalized upon by bad actors.

2.2 Use TLS for Login Pages

Web pages MUST use TLS, or similar protection, to protect both the solicitation and transmission of secrets, such as passwords, against disclosure to unauthorized parties.

2.3 Use TLS Consistently across the web site

If a web application solicits a secret, such as a password, over TLS, then it MUST always transmit that secret using that level of protection or better. Any derived secret that conveys a similar level of authority as the original secret MUST also be protected at the same level as the original secret. Other derived secrets SHOULD also be given the same protection. Sensitive transactions also MUST be protected using the same level of protection.

In a web application, a secret may be used to authorize a transaction. The details of that transaction SHOULD also be transmitted using the same level of protection afforded the secret itself.

Web sites SHOULD NOT serve mixed content, e.g., scripts or images served through plain HTTP connections when they control the appearance of a Web page served through TLS.

2.4 Redirects between Pages with Different Security Levels

Web Sites that require their users to be directed from an insecure web page to a secure web page MUST do it as a single step rather than multi-step (redirect to an unsecure page and then redirect again to a secure page). Web pages MUST use direct links to a secure page rather than using redirects.

Web Sites MUST NOT use unsafe redirection chains involving unsecured HTTP connections to navigate users from one secure page to another one. Instead, navigation within a secure site MUST use a consistent level of protection.

2.5 Security Experience Across Devices

Web content SHOULD be designed to enable a consistent security user experience across different user agents and devices. Web site owners SHOULD perform tests of the TLS security and trust features of their site on various devices.

Web site owners operating TLS-protected sites should anticipate the use of those sites from mobile devices which may have constrained capabilities e.g. diverging sets of trust anchors or limited cryptographic mechanisms.

2.6 Good Practices for the Creation of Audio Logotypes

Audio logotypes embedded with certificates should be designed to minimize possible listener confusion and the time that their rendering takes. Specifically, audio logotypes SHOULD NOT include spoken text. Audio logotypes MAY include short musical phrases.

3 Security Considerations

4 Acknowledgments

This specification is based on text from Thomas Roessler, Mary Ellen Zurko, Stephen Farrell, Ian Fette, Michael Mccormick, Serge Egelman, Johnathan Nightingale, Yngve Pettersen, as well as input and discussions from the active members of the Web Security Context Working Group. It has also benefitted from general public and working group commentary on earlier drafts.

5 References

ECRYPT Yearly Report on Algorithms and Key Lengths (2006 Edition), available at
The Emperor's New Security Indicators, S. Schechter, R. Dhamija, A. Ozment, I. Fischer, in Proceedings of the IEEE Symposium on Security and Privacy, May 2007. This paper is available at .
Guidelines for the Issuance and Management of Extended Validation Certificates, CA/Browser Forum, 7 June 2007, available at
How to Add a Favicon to your Site, D. Hazaël-Massieux, C. Lilley, O. Théreaux, W3C work in progress, available at .
Portfolio of recommended cryptographic primitives, New European Schemes for Signatures, Integrity, and Encryption (NESSIE), available at
Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, S. Bradner, March 1997, available at
Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999, available at
Upgrading to TLS Within HTTP/1.1, RFC 2817, R. Khare, S. Lawrence, May 2000, available at
HTTP Over TLS, RFC 2818, E. Rescorla, May 2000, available at
HTTP State Management Mechanism, RFC 2965, D. Kristol, L. Montulli, October 2000, available at
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3280, R. Housley, W. Polk, W. Ford, D. Solo, April 2002, available at
An Internet Attribute Certificate Profile for Authorization, RFC 3281, S. Farrell, R. Housley, April 2002, available at
Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates, RFC 3709, S. Santeson, R. Housley, T. Freeman, February 2004, available at
Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, T. Berners-Lee, R. Fielding, L. Masinter, January 2005, available at
The Secure Shell (SSH) Connection Protocol, RFC 4254, T. Ylonen, C. Lonvick, January 2006, available at
TWIRL and RSA Key Size, Burt Kaliski, RSA Laboratories, revised 6 May 2003, available at
Web Content Accessibility Guidelines 2.0, B. Caldwell, M. Cooper, L. G. Reid, G. Vanderheiden, W3C Working Draft 17 May 2007. This version of WCAG 2.0 is work in progress. This version is . The latest version of WCAG 2.0 is available at .
Use of Visual Security Cues in Web Browsers, T. Whalen and K. M. Inkpen. Gathering Evidence. In Proceedings of the 2005 Conference on Graphics Interface, pages 137–144, Victoria, British Columbia, 2005.
Web User Interaction: Threat Trees, T. Roessler, Editor, Editor's Draft (work in progress), 1 November 2007. This version is The latest version is available at .
Web Security Experience, Indicators and Trust: Scope and Use Cases, T. Close, Editor, (work in progress), 06 March 2008. This version is The latest version is available at .
Hardening web browsers against man-in-the-middle and eavesdropping attacks, H. Xia and J. C. Brustoloni. In Proceedings of the 14th International World Wide Web Conference (WWW2005), pages 489–497. W3C/ACM, May 2005, available at .