Security considerations in HTTP

W3C HTTP 1992

Security Considerations

The HTTP protocol allows requests to communication to a remote server machine, and all the expetant security considerations for client-server systems apply, including

The bulk of these are well known problems, tackled in part by some featured of this protocol. Some aspects particular to HTTP are mentioned below.

See also the Shen Security, S-HTTP and Digest proposals.

Unwitting actions on the net

The writers of client software should be aware that the software represents the user in his interactions over the net, and should be careful to allow the user to be aware of any actions he may take which may be taken as having an unexpected significance by others.

TCP port numbers

Clients should prompt a user before allowing HTTP access to reserved ports other than the port resrverd for HTTP (port 80). Otherwise, the user may unwittingly cause a transaction to occur in some other (present or future) protocol.

Idempotent methods

The convention should be established that the GET and HEAD methods never have the significance of taking an action. The link "click here to subscribe" causing the reading of a special "magic" document is open to abuse by others making a link "click here to see a pretty picture". These methods should be considered "safe" and should not have side effects. This allows the client software to represent other, methods (such as POST) in a special way, so that the use is aware of the fact that an action is being requested.

Abuse of log information

A server is in the position to save large amount of personal data about information requested by different readers. This information is clearly confidential in nature, and its handling may be constrained by law in certain countries. Server providers shall ensure that such material is not distributed without the permission of any people or groups of people mentioned in the results published.

A feature which increases the amount of personal data transferred is the Referer: field. This allow reading patters to be studied, reverse links drawn, and so is very useful. Its power can be abused of course if user details are not separated from the Referee-Referer pairs. Even when the personal information has been removed, the Referer field may in fact be a secure document's URI, whose revelation itself is breach of security. A method of suppressing the Referer information in such cases may be the subject of further study.