> I don't know anybody who works full-time in software security who thinks HttpOnly is a meaningful defense, but, if you're out there, chime in and make a case

> I don't know anybody who works full-time in software security who thinks HttpOnly is a meaningful defense, but, if you're out there, chime in and make a case for it. :) I'm going to mostly agree. It's only a meaningful defense against bottom-rung attackers who go after the lowest-hanging of fruit, and if you're susceptible to them, you've probably got bigger problems (in the server-side RCE realm). And of course, XSS means token-based SSRF/CSRF mitigations are completely toast in the absence of any extra controls (i.e. password re-prompts, CAPTCHAs). Rough and dirty pseudocode PoC for anyone who thinks different: // Assuming the token is in the HTML form, and tied to the session. // If it's in a cookie, just skip to $.post(): $.get("/url", {"arg": "value"}, function(data) { // ... Grep for token ... $.post("/url", {"arg": tokenGoesHere}); // pwnd }); What httpOnly does well is put the burden on the attacker to create a more explicit exploit than "grab the session ID and POST it to this external site so I can swoop in impersonating them at my leisure". They instead need to make the payload do all the commands they intended or connect back to await instructions. Is that a meaningful security gain? Not in the big scheme of things, no. "Not vulnerable to script kiddie tactics" isn't exactly a bragging right. The proper fix is, of course, to update your code and remove XSS vulnerabilities.