[HN Gopher] SPAs Are Dead?
___________________________________________________________________
SPAs Are Dead?
Author : wstrange
Score : 85 points
Date : 2021-04-07 18:07 UTC (4 hours ago)
(HTM) web link (leastprivilege.com)
(TXT) w3m dump (leastprivilege.com)
| ngrilly wrote:
| I don't like the click bait title, but the conclusion is
| interesting.
| [deleted]
| sly010 wrote:
| What the author describes was never a good idea anyway imho. We
| will just have to learn to point a subdomain to third party
| servers.
| echelon wrote:
| Or services we integrate with will have to start emitting the
| correct headers.
| _nhh wrote:
| I am currently involved in a app development where a single code
| base is deployed to several platforms.
|
| Cors is being a topic for the last two month. I am increasingly
| concerned about the future of javascript webapps and its build
| targets like cordova/capacitor/electron because there is no
| single cors configuration which fits all build targets :(
| maxharris wrote:
| I did web dev professionally for seven years until I started
| writing Swift a year ago. The learning curve for native iOS
| development is a little steep because Apple doesn't write
| adequate documentation, but resulting application delivers a
| superb user experience with extremely low power consumption.
|
| 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.
| hawski wrote:
| I hoped that designers learned something and decided to stop the
| war against their users. I did not hold my breath.
|
| 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.
| therealx wrote:
| Isn't it so relieving now that the pendulum is swinging back?
|
| 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.
| jmkni wrote:
| > I want my history, link copying, bookmarking, middle-clicks
| and Ctrl/Cmd-clicks to work as intended.
|
| In a well designed SPA, these will all work.
| hawski wrote:
| It's like with C or C++. Most people that do write it
| shouldn't, because they are not good enough or the process is
| broken and they will shoot their leg. SPAs are the same way,
| because you have to implement all those normal website things
| again by yourself. There will be casualties.
| jinushaun wrote:
| Exactly, the problem is that you don't get these baseline
| features for free. SPA, in my experience, is a lot of
| people poorly reimplementing the wheel.
| adrr wrote:
| They work perfectly fine under a SPA. SPA pushes history which
| lets the back button work and you can bookmark the URls. They
| have real URLs so you can create tabs.
|
| 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.
| darau1 wrote:
| Long ago Ruby on rails had a feature that sort of cached all
| links on the current page to make navigating to them faster.
| What happened to that? Would that not provide the same speed
| benefit? I'm ignoring the inefficient use of data here, ofc.
| drspacemonkey wrote:
| That would be TurboLinks. It's going strong, and has seen
| significant improvements over time. Especially when paired
| with something like Stimulus and/or Reflex and/or Hotwire,
| you can make some _very_ snappy feeling server-side
| rendered HTML. At this point, I won't even consider making
| SPAs for anything unless the product owner has an
| incredibly compelling reason.
|
| 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.
| nitrogen wrote:
| It's still a thing: https://turbo.hotwire.dev/
|
| 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.
| mrinterweb wrote:
| I think you're referring to TurboLinks. TurboLinks is still
| around. Building on that technology and moving towards HTML
| over socket is https://hotwire.dev/
| amelius wrote:
| If you have a history with multiple pages each with their own
| URI then it is not a SPA. SPA means "single page
| application".
| ccmcarey wrote:
| That's not true. Wikipedia [0] has a nice summary:
|
| > 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.
|
| [0] https://en.wikipedia.org/wiki/Single-page_application
| yawboakye wrote:
| You're getting a downvote treatment but I kinda agree with
| you that SPA shouldn't change history. But also, that was
| like the first versions of SPAs. The name stuck around
| (hello AJAX) while the underlying infrastructure and
| mechanisms great improved.
| andrewstuart2 wrote:
| "Page" is clearly too ambiguous as almost any acronym
| will be. The main tenet of a Single Page Application at
| least _used_ to be, before it was buzzworded into
| ambiguity, that the browser loads everything it needs
| once and makes round trips only for new data or
| incremental functionality. I think the same definition is
| still applicable, though. It never had anything to do
| with the information architecture of your UI or whether
| the majority of the screen might change between pages.
| And nothing to do with the URL or history; that 's all
| orthogonal and now can and should be done with deep
| linking and the history API to allow people to have
| faster feedback and still interact with sites in the
| browser the way they always have.
| adrr wrote:
| Single page load is the definition. The page never
| reloads. Even the first SPAs would uses url hashes to
| change the url before pushState was adopted.
| yurielt wrote:
| >and decided to stop the war against their users The thing is
| that the question is who are their actual users? Truth is just
| that we arent the actual users, by we I mean the tech savvy
| crowd we are a minorityand form what I have seen the majority
| of the users of notion are happier with they way it has
| evolved, and at the end of the day notion and places like it
| are going to follow that, I dont like it but this is usually
| what the war against their "users" is a byproduct of.
| hawski wrote:
| Every single day I see my wife and relatives struggle with
| modern computing. Not to say that previously it was much
| better, but web applications are increasingly different
| between each other in the way they work. They are not tech
| savvy, but are bitten in the ass by everything that computers
| have to offer, especially web pages. I am angry, because I
| know how it can all work better or see bunch of bugs in
| almost anything I use, but I can form quite easily
| workarounds, they can't.
| dragonwriter wrote:
| > I want my history, link copying, bookmarking, middle-clicks
| and Ctrl/Cmd-clicks to work as intended.
|
| 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.
| tshaddox wrote:
| In fact, in every modern JavaScript framework or rendering
| library I'm aware of, you have to go out of your way to make
| links that don't work with middle-click or page navigations
| that don't work with history and bookmarks.
| hawski wrote:
| I should start noting all those bugs, because I see them
| almost every day. But to be honest even "regular" web sites
| are guilty, especially with ctrl/cmd-click.
| tomComb wrote:
| I want all those things too, but not clear on how you think
| notion should be implemented.
|
| 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.
| gibsonf1 wrote:
| I think SPA's are alive and well using the Solid project [1] with
| Inrupt's auth library[2] that supports Open ID Connect PKCE with
| dpop tokens.
|
| [1] https://solidproject.org/ [2]
| https://github.com/inrupt/solid-client-authn-js
| jessaustin wrote:
| _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...
| throwaway185205 wrote:
| If I can trust 2018 OAuth-as-a-service vendor literature, it
| seems popular to signify "use grant flow X because your app has
| no backend."
| shortlived wrote:
| Sounds like JAM stack to me
| andrewstuart2 wrote:
| And the latter is not even true unless I missed something
| significant. It's just lazy implementations thereof that are
| dead. Having developed SPAs for much of my career, I did plenty
| of cross-site login and work never realizing third party
| cookies were even an option. I just figured they were bad
| practice and that oauth2, understanding the limitations of web
| frontend oauth2 security (e.g. can't really do a full
| authenticated client without a backend to keep secret the
| client secret), and using proper CORS was the right way to do
| it. I think that's the way forward with the removal of third
| party cookies, is it not?
|
| 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.
| takeda wrote:
| Why authors of these blog posts assume that everyone know what
| the context is? Even if one assume the term is related to
| computing and technology, there's 4 different things named SPA.
| Is it that hard to expand the term in the title or in the
| beginning of the blog to help people quickly decide if they are
| interested in it or not?
|
| 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.
| jeppebemad wrote:
| To be fair, most of the blogposts are not written for us on HN,
| but for the followers of the blog in question. I do not mind
| having to figure out the context, if it means I get to explore
| the esoteric and far corners of the internet from one place :)
| tus88 wrote:
| How do people bridge the SPA/ORM gap, when no such gap exists in
| serverside rendering?
| austincheney wrote:
| A better way to think about it: _Who wants SPAs more, UI
| developers or their users?_
|
| 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.
| CivBase wrote:
| Users just want pages to load fast. UI developers (presumably)
| just want to maximize user happiness.
|
| 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.
| austincheney wrote:
| It's hard to know what users want if those wants are assumed,
| which serves to reinforce bias.
| rory wrote:
| The general trend here seems that browser security improvements
| are more likely to kill core-function-of-your-app-as-a-service
| type software products, rather than SPAs in general or in
| particular.
| astro_sloth wrote:
| Long live the SPAs.
| arendtio wrote:
| What the article completely ignores, is the fact, that building
| cross site apps has been next to impossible for a long time.
| Since you can't contact a server who doesn't explicitly allows
| connections via CORS, your browser based app doomed.
|
| And I write this as someone who would love to build apps all day
| with web technologies.
| kreetx wrote:
| I don't quite get what you mean. If the cross-origin server (to
| your app) wants to be consumed then it will respond with the
| correct headers. And if the server is under your control then
| you can configure it so.
| zyemuzu wrote:
| This. I suppose that's what has me confused about both the
| blog post and comment, i.e. why would you not control your
| servers?
| kreetx wrote:
| Not entirely sure what parent meant but it seems that many
| web developers are still confused as to why they can't
| consume any site on the internet from the front end.
| arendtio wrote:
| For non-browser apps the server doesn't have to explicitly
| allow it. A simple curl can access any server it wants. If y
| browser based apps wants to access another server, that
| server needs to be configured to allow it (because of the
| Same Origin Policy) and how many servers do you know that
| allow anybody to access them via CORS?
|
| 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.
| kreetx wrote:
| I would think any service that wants to be consumed will
| have CORS configured?
|
| All else _should be_ forbidden, that is the whole point of
| CORS.
| layoutIfNeeded wrote:
| Well, WebDAV clients don't usually run untrusted scripts
| downloaded from random servers, so they don't need CORS.
|
| 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.
| Cederfjard wrote:
| Not all apps need to contact third-party servers, so the
| way you categorically claim that building cross site web
| apps is next to impossible seems a bit exaggerated?
|
| Edit: Unless you don't consider it "cross site" if you
| control the API server?
| paxys wrote:
| Sounds like an overreaction. The only thing affected by the
| browser changes is some third party authentication mechanisms,
| and those can be easily fixed (as mentioned in the article
| itself).
| stepbeek wrote:
| 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
| tshaddox wrote:
| Indeed, the intended audience seems to developers of SPAs which
| only use third-party authentication and data. The article even
| mentions "pretty much every authentication protocol - like
| SAML, WS-Fed and OpenID Connect." I'm obviously not in this
| intended audience, because in my experience this is an
| extremely niche SPA use case. I can't even think of a website
| that does this or would want to do this. Maybe if you want to
| build a third-party web client for something like Gmail or
| Apple Music?
| billti wrote:
| 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.
| weird-eye-issue wrote:
| This is how I prefer to do it. No CORS pre-flight requests and
| messing with CORS settings
| yitianjian wrote:
| Seconding (thirding?) this.
|
| I'm curious, are there any SPAs that _aren 't_ done this way?
| slowmovintarget wrote:
| The article is referring to all the myriad other things an
| SPA will bring in. Analytics, feedback components,
| interactive galleries, notification components, header
| components... you can sew a site together from SaaS
| components that all live in different domains.
|
| 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.
| preommr wrote:
| 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.
| weird-eye-issue wrote:
| 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.
| preommr wrote:
| > there was no way for me to misconfigure CORS.
|
| 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[1] 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.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTTP/CORS
| weird-eye-issue wrote:
| Yes there are a ton. Actually it was a bit of a pain
| setting it up that way. I'm using Cloudflare to dynamically
| route to S3 or an ALB based on the path. If Cloudflare
| didn't have that option I would have had to roll my own
| solution to defeat CORS which could have added in another
| point of failure
|
| Edit: I meant Cloudfront. I do that a lot
| beckingz wrote:
| app.example.com vs api.example.com ?
| true_religion wrote:
| Sure I've done that but only for SPAs that are totally
| anonymous, and deploy the api.example.com behind a CDN
| cache.
| dragonwriter wrote:
| > I'm curious, are there any SPAs that aren't done this
| way?
|
| 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.
| pier25 wrote:
| I prefer using cookies, but most SPAs actually use JWTs.
| jakelazaroff wrote:
| Cookies and JWTs are not alternatives to each other. You can
| store a JWT in a cookie.
| shock-value wrote:
| You can also store a JWT in localStorage and require an
| additional secure signature for it within a cookie (http-
| only). Best of both worlds.
| ivoecpereira wrote:
| If doing that, why not go full-mode and store JWT in cookie
| with http-only flag?
| shock-value wrote:
| There are good uses for page content to know what's in
| the JWT (display username, show logged-in status, etc).
| Cookies also have stricter size limits. Additionally,
| cookies by themselves are uniquely vulnerable to CSRF,
| although I guess these days using SameSite property
| correctly mitigates that.
| timw4mail wrote:
| 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.
| kadfak wrote:
| Leaking your auth tokens through XSS sucks more.
| asabil wrote:
| If you have an xss your problem is much bigger than leaking
| an ephemeral access token through localStorage
| leipert wrote:
| 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.
| AlbinoDrought wrote:
| Normal cookies are JS-accessible, but HTTP-only cookies
| should not be: "A cookie with the HttpOnly attribute is
| inaccessible to the JavaScript Document.cookie API; it is
| sent only to the server."
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Cookies#re...
| leipert wrote:
| Ah thanks! This is new to me. That is indeed a concern,
| but probably can be worked around, e.g. by proxying
| requests to third party domains through the same Domain.
| kreetx wrote:
| You can't make the browser to send you cookies for other
| origins so you won't be able to use them from your
| server.
| fractionalhare wrote:
| 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.
| dkarras wrote:
| 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.
| fractionalhare wrote:
| I am talking about a much more general class of security
| than just XSS. You're making perfect the enemy of good
| here - yes, of course XSS is not completely mitigated by
| httpOnly. That was not my point.
|
| 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.
| shock-value wrote:
| A good option is doing both.
|
| 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.
| dkarras wrote:
| I don't believe it adds any meaningful security that
| justifies the cost (development, testing, hardening,
| scaling the state across servers if necessary etc.) With
| security "more complicated" does not necessarily mean
| "more secure". Doing it without multiplying the number of
| ways things can go wrong is deceptively hard.
| shock-value wrote:
| With this method there is no additional per-user state,
| fortunately.
| dkarras wrote:
| Yes, just that with regards to security I've seen to many
| burned by "it can't hurt" processes. With your
| suggestion, assuming perfect implementation, I personally
| can't see where it would help. Like, if attacker can run
| js in your site, they can just set the cookie as
| necessary before making requests (if the cookie does not
| exist already) since that is something they can already
| do. If the cookie exists (most likely scenario), the
| browser will send it with each request anyways so no
| added security there either.
| anaphor wrote:
| 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.
| midrus wrote:
| 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.
| rwieruch wrote:
| Related to this I was always wondering where to store refresh
| tokens when using both, access token and refresh token.
| Reference: https://stackoverflow.com/q/57650692
| warent wrote:
| 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]
| tmpz22 wrote:
| Chrome extensions can also inject code via a content script
| and gather local storage data. You can't control what
| extensions people are running.
| minhazm wrote:
| That also applies to cookies. Users can run any browser
| or script to access your site and do whatever they want
| with the cookies.
| gigaftp wrote:
| In the context of a compliant web browser you can set a
| cookie as http only as to disallow access it via Js.
| fractionalhare wrote:
| No they can't, refer to the documentation on cookie flags
| and attributes like httpOnly:
| https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
| Jenk wrote:
| Not for http-only cookies it doesn't.
| wayneftw wrote:
| Meh. Working at a consulting shop I've seen hundreds of apps
| built with tokens stored in the big bad localStorage. It's
| easy, it works and if you don't load scripts from
| untrustworthy sources then there is no attack vector outside
| of rendering un-sanitized user input as HTML or browser
| extensions.
|
| 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.
| timw4mail wrote:
| 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?
| inetknght wrote:
| > _And I hope I never end up using any application developed
| this way._
|
| Slack _[0] has entered the chat.
|
| Jira _[1] 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).
|
| [0]: 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.
|
| [1]: 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_.
|
| > _Tokens stored in those storages you mention can be read by
| any javascript code, even third party._
|
| I don't doubt you. But I am not a javascript developer. I'd
| like it if you could link to some demonstrations of how that
| can be abused.
| notsureaboutpg wrote:
| localStorage doesn't work in many browsers' private modes, so
| no... it's not
| kostarelo wrote:
| By interface you mean.. the HTTP protocol? At least they can be
| scoped on the domain level. Browser storage can't.
| leipert wrote:
| Local storage and Session Storage are scoped per origin as
| well: https://developer.mozilla.org/en-
| US/docs/Glossary/Origin
| pmlnr wrote:
| origin != domain level. See
| https://publicsuffix.org/list/public_suffix_list.dat
___________________________________________________________________
(page generated 2021-04-07 23:02 UTC)