Shouldn't the browser evict non-HttpOnly cookies first to avoid overwrite from JavaScript?

[securitybits]

The current draft prevents cookies marked as 'Secure' from being overwritten or evicted from a non-secure origin (e.g., section 5.4), but it does nothing to prevent JavaScript from overwriting a cookie marked as 'HttpOnly' by evicting it from the cookie store. In current browsers it's therefore possible to tamper with the integrity of cookies marked with HttpOnly from JavaScript (e.g., XSS attack) despite the specification stating access should be restricted from non-HTTP APIs.

In my view we should protect both confidentiality and integrity for HttpOnly cookies, which could be done by adding a condition that cookies without the HttpOnly attribute should be evicted first when set from a non-HTTP API (e.g., JavaScript).

[johnwilander]

We now have SameSite cookies to consider too. Perhaps we should have a strict ordering of priority for these attributes and combinations of them?

[mikewest]

I'm wary of changing eviction rules more than we already have. We ended up breaking some Google sites with our Secure prioritization, and ended up with a somewhat complicated scheme to use https://tools.ietf.org/html/draft-west-cookie-priority-00 to solve the problem. I'm a bit reluctant to go through that again without some commitment from Apple and Mozilla that they'd be willing to do the same in much the same timeframe.

@johnwilander, @mozmark/@annevk: Is this something you could find out whether folks internally were interested in doing?