Remix clone Hacker News

Httponly cookie is the way, but then you just don't use json as cookie value that is send on every request.

Csrf is no problem as the data from service worker is only active on the site itself. If you speak about csrf with a website where you can't trust js, you're site is broken as xhr/fetch use the same httponly cookies and is affected as well.

▲

withinboredom 4 days ago | parent [-]

Since when can you trust js?

▲

0x073 4 days ago | parent [-]

Big websites use js and if they leak most of the time it's not a js issue.

I think the distrust of js is a personal issue.

▲

withinboredom 3 days ago | parent [-]

I mean, anyone can open devtools and change the code to do whatever ... or install an extension that does it. So, since when can you guarantee that a browser client will actually do what you program it to do? In my experience, you can't guarantee anything on the client -- since forever. I was asking when/if that changed. I don't see why you would make that a personal attack?

	▲	0x073 2 days ago \| parent [-]
		But that a general problem, having a html only page with a form is the same problem. Only transfer what the user should see. You need server verification for data that's important. Native programs can be changed with over programs or hex editor. The talk was about data that is stored into cookies as json and csrf. (Cookies can be changed with devtools or extension) Csrf is always an attack from third party against the user, if the user extract the data itself that's no csrf problem. Because of this I thought you distrust js that can get attacked from third party, but yes js is as easy to change like .net or java programs.