[danhite]

The article you cited was very informative.

For example it reminds that standards & intermediaries you trust might still allow multiple unconcatenated XFF headers though and the XFF unpeel by right to left heuristic fails if you only look at the e.g. the first such header.

This reminded me that there always seems to be a past or future pitfall case lurking, such as using old code/library honoring a X-HTTP-Method-Override header (e.g. historically used to ~convert POST to PUT bypassing client CORS restrictions).

Many holes I've noticed over the years seem to spring from legacy preservation of well intended endruns of restrictions, for example I can presently in Safari exploit a bug to get a crypto digest calculated for me within an insecure context ... I find this quite usefully locally (e.g. lan http: , data: , ~bookmarklets that I control) but nonetheless I reported the bug and am trying not to rely on it.