SPDY: Security Consideration

spdy

Snip from: http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

5.  Security Considerations

5.1.  Use of Same-origin constraints

   This specification uses the same-origin policy [RFC6454] in all cases
   where verification of content is required.

5.2.  HTTP Headers and SPDY Headers

   At the application level, HTTP uses name/value pairs in its headers.
   Because SPDY merges the existing HTTP headers with SPDY headers,
   there is a possibility that some HTTP applications already use a
   particular header name.  To avoid any conflicts, all headers
   introduced for layering HTTP over SPDY are prefixed with ":". ":" is
   not a valid sequence in HTTP header naming, preventing any possible
   conflict.

5.3.  Cross-Protocol Attacks

   By utilizing TLS, we believe that SPDY introduces no new cross-
   protocol attacks.  TLS encrypts the contents of all transmission
   (except the handshake itself), making it difficult for attackers to
   control the data which could be used in a cross-protocol attack.

5.4.  Server Push Implicit Headers

   Pushed resources do not have an associated request.  In order for
   existing HTTP cache control validations (such as the Vary header) to
   work, however, all cached resources must have a set of request
   headers.  For this reason, browsers MUST be careful to inherit
   request headers from the associated stream for the push.  This
   includes the 'Cookie' header.