Web Forms

On the client side, implementors must be aware of a number of potential attacks. Since it is relatively easy for a hostile Web site to trick users into loading hostile content, for example by sending e-mails claiming to include links to photos of naked girls, users must be confident that a hostile site cannot access confidential information, perform denial-of-service attacks, or hijack the client's host to perform actions on behalf of the user that the user may not approve of.

Confidential information can be stored in several places. Documents from other servers loaded into other browsing contexts (e.g. other windows), documents from other servers that the hostile page has caused to be loaded (of particular concern being pages that include user-specific information using out-of-band authentication and/or authorisation information such as HTTP cookies, HTTP authentication, or the origin host), files on the local system, as well as details of the user's configuration are all potential sources of confidential information.

User agents must therefore implement security mechanisms to block cross-domain accesses (where local files are considered a separate domain). Such mechanisms are referred to as cross-domain scripting security mechanisms. Unfortunately, since it is difficult to predict exactly what attack vectors may exist in such a complex system, and in particular because it depends on the exact feature set of the implementation, this specification does not define the exact mechanism that must be implemented.

In practice user agents implement quite comprehensive cross-domain scripting security mechanisms. Implementation experience has shown that such security mechanisms must, at a minimum, prevent scripts originating from a site at one domain from accessing the properties and methods of any object (in particular, DOM nodes) associated with a page from another domain. Typically, such an access would cause an exception to be raised.

Denial of service attacks are naturally hard to prevent, since they frequently are hard to distinguish from legitimate behaviour. Implementors are encouraged to set arbitrary (although high) limits on what an author can do. For instance, user agents might place a limit on the length of the regular expression pattern allowed in the pattern attribute, if a long expression could be made to take unacceptably long to execute.

Implementations are also asked to consider how otherwise-legitimate UI could be abused by a hostile page. Naturally, since implementations are not restricted in how they implement their interface, no specific guidelines can be given. One example, however, would be the mailto: submission feature. Since a script can artificially submit a form, it is important that the UA not cause each submission to create a new mail window, since this would allow authors to overwhelm the user with windows containing author-specified text, which could act as both a denial-of-service attack, and an annoying advertising technique.

Finally, user agent implementors should prevent pages and scripts in those pages from performing potentially harmful or embarassing actions on behalf of the user without the user's knowledge.

For example, it is recommended that user agents limit the ports to which forms may be submitted, excluding, in particular, ports of well-known protocols like SMTP or telnet. The SMTP port in particular has been used by hostile pages in the past as a target of form submissions for the relaying of spam by unsuspecting users.

Certain actions, including submitting a form to a third-party site and making HTTP GET requests to remote sites (both of which would be blind attacks, assuming the UA implements a cross-domain scripting security mechanism) have been historically allowed, and many sites depend on these features for quite legitimate uses. User agents should allow them.

Servers therefore must also consider security. Servers should never perform non-idempotent actions in response to GET requests, as discussed by the HTTP specification. Servers should also check the Referer header to ensure that only requests from trusted hosts are honoured.

Servers should also consider the client to be untrusted, since in most scenarios requests can be made to hosts by hostile parties directly, bypassing any security logic included in the page nominally intended to perform the submission. Thus servers should perform validation on all submitted data, whether such validation is expected to be performed on the client or not.

Further specific securiy considerations are called out where relevant.