Hacker News Reader

Comment by nchmy | Hacker News Reader

I deeply appreciate this thorough review of CSRF protection via headers. I've been looking into the topic to see if I can get rid of csrf tokens, and it seems like I can now - if I ignore/don't care about the 5% of browsers that don't support the required headers.

It makes me wonder though - most browser APIs top out around 95% coverage on caniuse.com. What are these browsers/who are these people...? The modern web is very capable and can greatly simplify our efforts if we ignore the outliers. I'm inclined to do so. But am also open to counterarguments

View on HN

From business perspective it makes a lot of sense to just drop that bottom 5%. Actually, many businesses support Chrome only, they don't even support Firefox.

Technological counterargument though is that you should allow people to tinker and do weird shit. Once upon a time tech wasn't about maximizing stock value, it was about getting Russian game crack to work, and making Lora's boobs bigger. Allowing weird shit is a way to respect the roots of modern tech, and allow hobbyists to tinker.

Thanks for confirming. I don't know that it has to be framed as a "business perspective" though. I'm a solo dev for a non-profit project, so ignoring the 5% is just a matter of pragmatism.

I most defintiely do not care about tinkerers, and in fact would generally classify them as something akin to attackers. I just want to allow as many people to use the app as possible, while keeping things simple and secure.

Empathy and accessibility. Does it make sense to have a ramp in front of your shop for < 5% customers?

My question, though, is who are the 5% of users in this case who are using some arcane browsers? Surely that's largely a choice, physical disabilities are not.

It doesn't seem unreasonable to say to those folks "were evidently not using the same web"

It's not comparable to a physical disability byt gatekeeping the people who just don't want to be tracked all day by Google doesn't sounds right to me though.

There's plenty of other chromium browsers - Vivaldi seems to do a good job in this regard.

Also, Firefox exists, though they don't seem to care about privacy much anymore either.

And, of course, safari, which is terrible in most regards

> There's plenty of other chromium browsers - Vivaldi seems to do a good job in this regard.

Being chromium derivatives, they don't really have a say in what's included in “their” browser though.

> Also, Firefox exists

Well, you disregarded is as “arcane browser” right above.

In what way did I call Firefox arcane? Firefox generally has better support for web features than safari.

It has less than 5% market share left…

it is included in Baseline and passes more tests than safari, so i would hardly call it arcane

Yet people treat it as such and drop support. Remember this is the comment you argued in favor above: https://news.ycombinator.com/item?id=45590086

> From business perspective it makes a lot of sense to just drop that bottom 5%. Actually, many businesses support Chrome only, they don't even support Firefox.

Grandma or poor folk with their old device may not be "largely a choice"

Don't major browsers essentially auto update? And to the extent that a device is so old that it can't support newer versions, surely it must be VERY old and perhaps is somewhat likely to be replaced sooner than later.

I think I'll probably carry on with not supporting browsers that don't have Sec-Fetch-Site. The alternative, Csrf tokens, actually causes me immense issues (they make caching very difficult, if not impossible).

(and I say all of this as someone who is specifically building something for the poorest folks. I'm extremely aware of and empathetic to their situation).

It still depends on the target audience. Some websites or apps are single-page applications (SPAs), can older devices handle that? For example, my mum’s Android phone was too slow to even load a page.

Secondly, users should upgrade their devices to stay safe online, since vulnerabile people are often scammed or tricked into downloading apps that contain malware.

So we should not cater to outdated browsers when they could pose a risk.

Yeah, I'm very amenable to this take. WordPress, for example, is infamous for having extreme backwards compatibility. But that often results in many sites being on ancient versions of php (and surely other tech as well). I'm of the opinion that they should all be running currently-supported versions of php and everything else. If you can't use my plugin because your server is shit, so be it.

Should we build SPA given it's poorly accessible and provide bad performance?

Tried old school SSR? Even on modern devices, it's waaaayy faster and much more enjoyable than JavaScript bloated "modern" website.

For a lot of businesses, 5% of revenue is a lot more than the cost of supporting older browsers

What shifts the discussion a bit is that many of the bottom 5% aren't lost customers. If your website doesn't work on my minority browser, smart TV or PS Vita I might be willing to just try it in Chrome instead

Those 5% are probably a wild collection of devices. TVs with embedded Browsers, old phones and other computers elsewhere.

As example: my late grandfather of 100 years took records of his stamp collection in Excel. He used the computer for Wikipedia as well, but we didn't upgrade ist as he was comfortable, but upgrading to later Windows to ruin newer browser would have been too much of a change and rather made him stop doing what brought him fun. The router etc blocked worst places frequent backups allowed restore, thus actual risk low.

Anecdote aside: there are tons of those machines all over.

And then another big one: bots claiming to be something which they aren't.

There are a lot of people happily browsing away on unsupported Apple devices that don't get any more Safari updates. Lot of strange webkit edge cases to be found that don't exist in any other browser.

Apparently less than 1.5% of global internet users are on versions of safari that don't support Sec-Fetch-Site.

That's a lot of people...

If a browser is too old to send either the Sec-Fetch-Site header or the Origin header, it will probably ignore Referrer-Policy and always set the Referer header, which contains the origin.

So I wonder why the author didn't consider falling back to the Referer header, instead of relying on an unrelated feature like TLS 1.3. Checking the referrer on dangerous (POST) requests was indeed considered one way to block CSRF back in the day. Assuming all your pages are on the same https origin, is there an edge case that affects Referer but not the Origin header?

Caniuse.com shows both origin and referer headers have 96.3% support, with Sec-Fetch-Site not far behind at 94.2. So it's probably a moot point.

Ive read in various places though that referer has all sorts of issues, gotchas etc such that it isn't really a reliable way of doing this.

https://security.stackexchange.com/questions/158045/is-check...

Caniuse.com looks wrong in this case. It marks old versions of Internet Explorer and Android browser as either unknown or not supporting Referer, when in fact they only lacked support for hiding the Referer in potentially insecure situations. That's the point I was trying to make above. Even old browsers send it, even when they shouldn't. This behavior is uncontrollable, even by potential attackers.

A missing Referer header probably doesn't mean much one way or another. But you can at least block requests with Referer pointing to URLs outside of your origin. This fallback would seem preferable to the fail-open policy described in the article (request always allowed if neither Sec-Fetch-Site nor Origin headers are present).

Reply on news.ycombinator.com