That just shifts the problem, because then you only need the encrypted token instead of the cookie within it.
This is a fundamental limitation of client-side authentication: it's only enforceable insofar as the browser wants to enforce it. You can protect your token in browser memory from pages on other origins, by relying on well-known behavior of the same origin policy sandbox. But you can't protect it from a modified script on your own page, or an alternative client (like curl) that fetches from the API directly and has no same origin policy.
This comes up all the time, like when Snapchat wants to prevent unauthorized API usage but needs to ship a key in the client bundle, or when Google Maps wants to rate limit requests from an origin. Anyone with root (or really any external observer of the client sandbox) will always be able to obtain the key, or change what they do with it. So Snapchat can pin its HTTPS requests, but users can disable pinning on the client. And Google can reject requests from an origin that doesn't match the provided site key, but only for requests sent from a browser that enforces the same origin policy.
In most cases these limitations are "good enough," but front end devs can sometimes get careless and store what should be a server side secret on the client side. This is why products often have a "site key" and an API secret - they have distinct purposes because the site key should be assumed public.
