HTTP is used for Internet communications, so developers of applications, information providers, and users should be aware of the security restrictions in HTTP/1.1. This discussion does not include definitive solutions to the issues mentioned here but makes some suggestions to reduce security risks.
Often, HTTP clients are confidential to large amounts of personal information such as user name, location, mail address, passwords, encryption keys, etc. So you should be very careful not to involuntarily leak this information to other sources via the HTTP protocol.
The document should be limited to the documents returned by requests from HTTP to be only those intended by server administrators. Unix, Microsoft Windows, and other operating systems, for example, use '..' as a path component to indicate a directory level above the current level. An HTTP server on such a system MUST disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to be accessible through the HTTP server.
Clients using HTTP rely heavily on the Domain Name Service, and are therefore generally prone to security attacks based on the deliberate mis-association of IP addresses and DNS names. So clients must be cautious in assuming the continued validity of an association of IP number / DNS name. If HTTP clients cache the results of hostname searches to achieve a performance improvement, they must observe the DNS-reported TTL information. If HTTP clients do not observe this rule, they may be spoofed when the IP address of a server that has been previously accessed changes.
If a single server supports multiple organizations that do not trust each other, then the values of the Location and Content-Location headers must be checked in the responses generated under the control of those organizations to ensure that they do not attempt to invalidate resources that they have no authority over.
Existing HTTP clients and user agents typically retain information about the authentication indefinitely. HTTP/1.1 does not provide a server method for directing clients to discard these cached credentials which represent a major security risk.
There's a number of work around the parts of this issue, so it's recommended to use password protection in screen savers, idle time-outs, and other methods that mitigate the inherent security issues in this issue.
HTTP proxies are men-in-the-middle, and are a chance for man-in-the-middle attacks. Proxies have access to information related to security, personal information about individual users and organizations, and proprietary information belonging to users and providers of content.
Proxy operators should protect the systems where proxies are running, as they would protect any system that contains or carries sensitive data.
Caching proxies provide additional potential vulnerabilities since the cache contents are an attractive target for malicious use. Thus the content of the cache should be protected as sensitive information.