Has the latter ever been a definition of "SPA"? One would have thought the acronym "single page application" to have been fairly precise...
I guess I'm more surprised that somebody was using third party cookies for non-tracking purposes than I am surprised they're being removed.
> Some people recommend replacing silent renew with refresh tokens. This is dangerous advice – even if your token service has implemented countermeasures.
If I follow the link the author is clearly talking about public clients, which are always going to have significant security limitations. Somewhere else on the site he mentions BFF (backend for frontend) architecture as a mitigation. Which I kinda thought was the whole point of confidential vs public oauth2. The spec is super clear that public is less secure which is just the nature of security; if you have to ship a secret to someone who shouldn't know it, but they need to use it, you're kinda out of luck.
I think I'm picking up that the author's definition of SPA is also assuming no back-end, in which case many of the security points make a lot more sense. But even if you just throw out a secure authenticating proxy, which can be done with very little code and a few off-the-shelf and OSS products, you're back in business and more secure than ever.
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.
I'm curious, are there any SPAs that aren't done this way?
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.
This is a pretty big issue because there are a shit tonne of bad resources that poorly explain CORS - so many places just slap a wild card in 'access-control-allow-origin', and call it a day.
Even a lot of the framework middleware can be confusing and unhelpful.
FWIW, once I actually got it setup, it was very simple, very easy. I highly recommend MDN's CORS page as the only source someone should read, and to read the whole thing to actually learn it rather than just grabbing a library to solve the problem in 15 minutes.
Even then, I had to start with a small test project and test things at different levels to understand what a library would be doing. My back end is golang, and I used gorilla/mux, so I did things step by step to really know what was working and what wasn't. I've done it other ways with something like Spring boot and libraries where it's just a goddamn mess because it tries to automate too much for you and it becomes way too confusing.
Well... you could. Harder now.
From the article:
> So are SPAs dead? Well – 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.
For…enterprise reasons…the SPAs I’ve worked on in $DAYJOB use apis hosted in a separate subdomain (and, therefore, origin) than the page itself, meaning we have all the CORS headaches. But, certainly, segregating by path rather than domain is a lot more convenient if you control both the page and the APIs it consumes.
Edit: I meant Cloudfront. I do that a lot
Web apps and APIs are not the answer to the biggest problem we have today, which is the lack of open alternatives to Apple's App Store and Google's Play Store. While it is true that Apple cripples their browser to make web apps second-class citizens, browsers will always add a layer of indirection. Even if the performance loss were made negligible, it would encourage the creation of user interfaces that target the lowest common denominator available on all platforms.
In my opinion, the best way to fix this situation in the long-run is to design completely open mobile devices. I'd love to replace my iPhone and iPad with devices that are repairable and run a mobile-optimized version of Haiku. We're not as far off from that as you might think; metal 3D printers such as the Markforged Metal X will make it easier and cheaper than ever to make cases that turn a pile of parts into a working phone.
What does this have to do with web apps? Well, if you're spending all your time keeping up with web development, perhaps it's time to learn some new skills and push things forward in a different direction.
And I write this as someone who would love to build apps all day with web technologies.
So take for example a WebDAV server. In theory, you could build a web based app, that can access any WebDAV server out there on the internet. In practice, that WebDAV server requires a special CORS configuration in order to be accessible via a browser from a different origin. Any other normal desktop app doesn't care about CORS and can access any server it has credentials for, no matter what configuration it has.
Edit: Unless you don’t consider it ”cross site” if you control the API server?
All else should be forbidden, that is the whole point of CORS.
All non-browser based app needs no CORS setting
So every server, that is not specifically designed to accept connections from browsers, cannot be reached by browser based apps. And that in turn is a serious disadvantage for these apps, because it eliminates a complete class of use-cases.
Yes, if you control both ends you can make it possible, but if you want to build an app that is able to simply connect to any server out there, you will be in trouble.
Any server not configured to reply with permissive CORS headers doesn't want to handle your cross-origin requests. I.e they are not "public areas" for anyone to consume but serve just their own front end.
CORS is a security measure to make it safe to consume cross-origin servers from browsers, both with and without credentials. Otherwise, with credentials you could read client data for some other service. and without credentials you could just use that service's resources without having permission. CORS gives the service operator a method to give permission.
Querying other servers from your back end is another story entirely. CORS isn't required there but also, your server doesn't have access to any of the credentials available in the browser so you wouldn't be able to get any client-specific data. You can get any other data of course, but because this is a server it's easier to block, perhaps by IP or adding captcha.
Clients that aren’t browsers don’t generally have access cookies or similar user credentials for third party services as a result of user interaction with those services that allow exfiltration of data without user intent in the absence of SOP.
SOP is a solution to a browser-specific security issue.
Indeed, it is, but in my opinion a pretty bad one as it causes a lot of collateral damage. Instead, they should just use the (cookie) state from the origin that initiates the request instead of the origin that receives the request. AFAIK, that should have solved the security issue much more precisely. But now we have to live with the SOP+CORS in the web based world :-/
In this sense (i.e. running dubious scripts from random untrusted sources) the closest thing to browsers would be npm, although its centralized nature (mostly) prevents malicious actors causing too much damage.
So if you want to build a classic client app it would be independent from the server implementation. So maybe it would even be 'your' that you would use. For example you could built an app that could talk to a Dropbox server. But with the current SOP setup you would require Dropbox to configure their CORS accordingly.
If the demands of the developers out pace the demands of their users AND those demands primarily determine product design decisions the product is not all designed to benefit the user despite developers pleadings to the contrary. That is a very pronounced example of bias.
A SPA is just a way to front-load resources for a website so users don't have to re-load redundant resources for each new page. Whether that is actually worthwhile for the user depends largely on how many redundant resources a site has and how many pages a user is likely to request in a single session. SPAs are a situationally useful tech just like blockchain, machine learning, JS component frameworks, etc.
Sorry for the rant, but this is not the first time the article forced me to read it before I could decide if I'm interested in it.
To clarify I have nothing against actual web applications like an image editor or a game. However a wiki (I don't appreciate Notion), an online shop or a damned blog should not be one. I want my history, link copying, bookmarking, middle-clicks and Ctrl/Cmd-clicks to work as intended.
Go look at https://www.target.com/ and see if you can tell difference between SPA and regular web page except for the speed aspect.
HTML fragments are not all that less efficient than JSON on the wire, and they are much more CPU efficient for low-powered client devices.
If you're curious what the modern state of server-side HTML Rails can be from the user's perspective, head over to hey.com and sign up for their free trial.
> A single-page application (SPA) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the web server, instead of the default method of the browser loading entire new pages. The goal is faster transitions that make the website feel more like a native app.
I'm so glad I moved into C# and non-web dev/management and got out of that rat race. Tech always swings back and forth, but I'm so very happy to have made it past SPAs being the end all be all.
In a well designed SPA, these will all work.
Solutions for all of those for SPAs have been around for quite a while. Whether any particular SPA uses them or not is, of course, variable, but there is nothing inherent to SPAs that prevents them from working.
I use it exclusively in the browser on a laptop. I find it slow but I do not think that is the fault of browser tech or SPA architecture, and I assume it will get addressed.
Browser storage (sessionStorage, localStorage) is perfectly valid for storing an authentication token.
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 you're sending your password in plain text without HTTPs, then saying "ok, nevermind, we already have that problem so let's just not use any CSRF protection" you're just making things worse.
Authentication tokens that allow anyone reading them to impersonate you are bad, no discussion about it. Go and google for this if you don't believe me. Ask any security expert (which I'm not).
Cookies have the exact same problem. Except if you set the http-only flag in them, which is what I'm advocating for here.
You can still use localStorage, just not for security tokens.
Slack  has entered the chat.
Jira  has entered that chat.
I could go on but I don't need to. Many web applications that people use store an unnecessarily obnoxious amount of data locally. I can only imagine how much of that is used just once or possibly even never (like images in settings windows that were never accessed).
: On one instance of Firefox on one computer, app.slack.com has stored 1.9GB. On another instance of Firefox on another computer, app.slack.com has stored about 633KB. On a third instance of Firefox on yet another computer, app.slack.com has stored about 600MB.
: Jira doesn't load _at all_ if you've got any secure settings enabled (like... no CORS and no cross-domain cookies and no cross-domain XHRs and ... the list goes on). So Jira loads in an incognito window in a VM. But suffice to say that its local storage is even more _fucking obnoxious_.
I'm saying you should not use for SECURITY tokens which, if leaked, can allow others to impersonate your user. So it doesn't matter it uses 40Gb of cached data. Security is not black or white, it is a full spectrum and despite it would be bad for a hacker to obtain a full chat historory or your list of jira card titles it is still less worrysome that somebody able to impersonate you in those services. Security is an arms race....you need to raise the barrier more and more as attacks get more and more sophisticated. So the "then just don't run extensions" or "just don't use untrusted third party scripts", despite it is something we should do, it is not a justification for lowering the bar of all the other stuff we should be doing.
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?
No, it can't. Read about http-only cookies.
We've dealt with plenty of security issues and exactly zero of them centered around XSS. I've seen more issues surrounding bad dependencies that could end up running right inside your API server. Browser extensions can do so many other things, like reading all the forms and middling your API requests. So, I can't take responsibility for that.
I would recommend http-only cookies over localStorage, but if you protect yourself in other ways then putting auth tokens in localStorage is not the end of the world. It hasn't ever affected us, so I'll leave the pearl-clutching over this up to the experts.
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.
My actual point stands, the Web Storage API doesn’t offer the same protections as cookies. Don’t store sensitive data in localStorage, that is emphatically not it’s intended use.
I can't think of a scenario in this context where an attacker says "damn he is using http-only cookies, I won't be able to do what I want to do"
The only pragmatic difference between both is js accessibility. That only matters when someone can inject scripts into your site. My point is, when that happens, cookies are also bust.
Store a security token in localStorage and additionally store a secure signature for it in a secure, HTTP-only cookie. On your backend, verify validity of both the token and its additional signature contained in the cookie.