Canmove, confirm
1,537
edits
Changes
m
→Sec-From header proposal for CSRF and clickjacking mitigation
Generally, the Sec-From header aims to provide a bit of context with HTTP requests so that servers may make educated decisions on whether or not to serve data, accept request data for state-changing transactions, or continue with a persistent session. This is accomplished by specifying a list of sites that indirectly caused a request (the redirect chain) and the immediate "Origin" of a request, or the entity that most recently caused the request to happen. This Origin may be a host name or the string "null" in the cases where a request may have been falsely or deceptively generated.
== Changes from Previous Proposal (Origin) ==
There were a number of factors that caused this proposal to change from a model that helps prevent clickjacking to what is proposed here. An earlier proposal suggested providing the chain of frames as well as the origin of the request.
However, the '''chain of requests''' (i.e., redirects and referrer) that cause a document to load and the '''layout context''' in which a document will be rendered seem to be useful in different cases; the data points for "how you get something" versus "what you do with it" solve pretty orthogonal problems and we don't want to add complexity to Origin/Sec-From if it means a significant delay in adoption.
Knowing the frame chain is indeed useful, but it seems helpful when solving problems different from those originally targeted by a feature like Sec-From. For example, clickjacking prevention (one of the uses for the layout context or frame tree) seems most appropriate on the client side where the framing takes place, so it seems to me that sending this data to the server might not be a best course of action.
There are other features in the works that will hopefully fill the need for clickjacking prevention ([[Security/CSP|CSP]] for example).
= Sec-From header format =
