41–50 of 118 posts
And I write this as someone who would love to build apps all day with web technologies.
Earlier quoted context omitted.
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.
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 :(
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.
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.
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…
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
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.
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...
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.