Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPAs Are Dead?

leastprivilege.com

Post reply on HN
Print view View original

31–40 of 118 posts

Re: SPAs Are Dead?

#31

Post by dkarras »

fractionalhare wrote: post #19
leipert wrote: post #14

Earlier quoted context omitted.

I don’t know whether you are referring to only local and session storage being feasible or not, but on can access cookies from JS as well.

Which is why you use domain scoping, httpOnly and Secure cookie flags so they can only be read by matching hosts (with greater granularity than same-origin policy) over HTTPS and can’t be read by JavaScript. The Web Storage API does not offer these protections.

They can't be read BUT the browser will send the cookie with every request. If you have an XSS, it is game over. The attacker can just send requests from your browser. Slightly less convenient. You are merely taking away the convenience of the attacker doing the attack manually on his own browser, which he probably doesn't want to do anyways. If he can inject js into your site, he will make your browser send the request(s) to do the actions with your credentials in an automated and quick way. Your browser will send the cookie automatically. From the attacker, it would merely be nice if he could read your tokens, but it is absolutely not necessary.

Like some here, I don't understand the hate around keeping tokens in localstorage. People immediately say "but js can read it!" but so what? If someone can put malicious js in my site, it is GAME OVER, secure http-only cookie or not. When that is the case, the saner option is doing away with an old and misused invention called cookies. The upside with ditching cookies is that you are an order of magnitude safer against CSRF since your browser does not send anything automatically. You don't need to keep CSRF token state in your server(s) either (helps with scale, one less state to worry about), it is a win.

http-only secure cookies do not give you any additional security. Ditching cookies does.

Re: SPAs Are Dead?

#32

Post by preommr »

yitianjian wrote: post #5
weird-eye-issue wrote: post #3

Earlier quoted context omitted.

This is how I prefer to do it. No CORS pre-flight requests and messing with CORS settings

Seconding (thirding?) this. I'm curious, are there any SPAs that aren't done this way?

I have my backend on a different subdomain instead of a subdirectory because it solves issues at the dns level. This means I don't have to deal with setting up a reverse proxy or separate rules for cloudflare.

This applies not only to production but also for local testing. I used to have a reverse proxy for local development.

Moreover it gives you better security by default since different backends are now treated as different origins, so same-orign-policy, and same-site (for cookies) kicks in.

Re: SPAs Are Dead?

#33

Post by shortlived »

jessaustin wrote: post #26

SPAs as in the UI/UX concept certainly not. SPAs as in “browser-based standalone applications that do cross-site authentication and API calls in the context of a modern identity and SSO architectures” – yes. Has the latter ever been a definition of "SPA"? One would have thought the acronym "single page application" to have been fairly precise...

Sounds like JAM stack to me

Re: SPAs Are Dead?

#34

Post by pmlnr »

leipert wrote: post #15
kostarelo wrote: post #10

Earlier quoted context omitted.

By interface you mean.. the HTTP protocol? At least they can be scoped on the domain level. Browser storage can't.

Local storage and Session Storage are scoped per origin as well: https://developer.mozilla.org/en-US/docs/Glossary/Origin

origin != domain level. See https://publicsuffix.org/list/public_suffix_list.dat

Re: SPAs Are Dead?

#35

Post by [deleted] »

warent wrote: post #25
midrus wrote: post #13

Earlier quoted context omitted.

No, it is not. And I hope I never end up using any application developed this way. Tokens stored in those storages you mention can be read by any javascript code, even third party. That doesn't happen with http-only cookies. Be careful with what you recommend publicly, as others might end up assuming this is fine, when it is clearly not.

If your third party libraries are so poisoned that you're leaking localstorage, you've got bigger problems than just localstorage... This argument against using localstorage makes no sense

[deleted]

Re: SPAs Are Dead?

#36

Post by minhazm »

tmpz22 wrote: post #29
warent wrote: post #25

Earlier quoted context omitted.

If your third party libraries are so poisoned that you're leaking localstorage, you've got bigger problems than just localstorage... This argument against using localstorage makes no sense

Chrome extensions can also inject code via a content script and gather local storage data. You can't control what extensions people are running.

That also applies to cookies. Users can run any browser or script to access your site and do whatever they want with the cookies.

Re: SPAs Are Dead?

#37

Post by weird-eye-issue »

preommr wrote: post #32
yitianjian wrote: post #5

Earlier quoted context omitted.

Seconding (thirding?) this. I'm curious, are there any SPAs that aren't done this way?

I have my backend on a different subdomain instead of a subdirectory because it solves issues at the dns level. This means I don't have to deal with setting up a reverse proxy or separate rules for cloudflare. This applies not only to production but also for local testing. I used to have a reverse proxy for local development. Moreover it gives you better security by default since different backends are now treated as…

Yeah I used rules in Cloudfront for this. Only have one API backend so security doesn't really factor into this much. Actually I consider it slightly more secure because there was no way for me to misconfigure CORS.

Re: SPAs Are Dead?

#38

Post by billti »

stepbeek wrote: post #2

Maybe I'm missing something, but this seems like a very narrow definition of SPA. A SPA can just sit on a different path from the API server and cross-site cookies aren't a problem. For instance, www.example.com/app and www.example.com/api

That's what I moved our stuff too, because it was just easier for a number of reasons (cookies and CORS stuff being amongst them). Any calls to other domains are done through the API hosting on the site domain.

He does allude to that at the end of the post though: "So are SPAs dead? ... SPAs as in “browser-based standalone applications that do cross-site authentication and API calls in the context of a modern identity and SSO architectures” – yes.". That is a narrower definition though.

Re: SPAs Are Dead?

#39

Post by timw4mail »

midrus wrote: post #13
timw4mail wrote: post #4

Cookies suck. The interface is beyond terrible, they were never scoped properly, and they don't have to be used. Browser storage (sessionStorage, localStorage) is perfectly valid for storing an authentication token.

No, it is not. And I hope I never end up using any application developed this way. Tokens stored in those storages you mention can be read by any javascript code, even third party. That doesn't happen with http-only cookies. Be careful with what you recommend publicly, as others might end up assuming this is fine, when it is clearly not.

So the article is about being unable to access third-party cookies due to browser privacy updates.

1. If you are using Http-only cookies, these are clearly unrelated. 2. If you are sharing an authentication token with the browser, cookie or not, it can be read by any scripts on the same origin.

So...what exactly are you trying to say?

Re: SPAs Are Dead?

#40

Post by anaphor »

dkarras wrote: post #31
fractionalhare wrote: post #19

Earlier quoted context omitted.

Which is why you use domain scoping, httpOnly and Secure cookie flags so they can only be read by matching hosts (with greater granularity than same-origin policy) over HTTPS and can’t be read by JavaScript. The Web Storage API does not offer these protections.

They can't be read BUT the browser will send the cookie with every request. If you have an XSS, it is game over. The attacker can just send requests from your browser. Slightly less convenient. You are merely taking away the convenience of the attacker doing the attack manually on his own browser, which he probably doesn't want to do anyways. If he can inject js into your site, he will make your browser send the requ…

I think some people don't realize that CSRF tokens are basically the same thing as bearer tokens (which JWT also does), but it's just that they get re-generated every time you open a new page usually. So it's a bit ironic when everyone screams that tokens are bad, but they're all using them to protect against confused deputy attacks.
Post reply on HN