Your session/auth tokens will always be exposed to some level of risk when stored on the client machine... for example, if you have physical access to the person's browser and they are logged into a service, you could use browser developer tools to view all their cookies and local storage key/value content.
HTTP-Only Cookies and Local Storage are not inherently insecure, but can be vulnerable if there is some other exploitable functionality on your website.
So there's some things you can do to mitigate the risk...
Short-lived session tokens will help to mitigate risk inherent from stolen tokens by reducing the time an attacker has to take advantage of the stolen token. The less time they can exploit a stolen token, the better.
XSS attacks are a little trickier with local storage. Both local storage and cookies are protected by allowing only access to code loaded from the same domain. So if the script injection originates from code loaded on the same domain the local storage value originates on, then it may be vulnerable.
You can help protect cookies and local storage by carefully managing where functional code and user-generated content load from, but this is a rather advanced technique. It takes some careful consideration.
Cross-Site Request Forgery (CSRF) attacks should not expose local storage values, but can expose content that is protected by cookie values.
CSRF works by loading content from your domain, on an attacker's page. With your website properly configured, Cross-Origin Resource Sharing (CORS) will help protect content/actions that are typically at-risk of exploit by CSRF. CORS is not fool-proof, though. So it's usually better to use a stronger mitigation like a CSRF token.