0

I am currently writing a project and looking to implement the JavaScript Cache interface in order to prevent redundant API calls. My concern here is that by caching the API calls (which contain the users API credentials), it will potentially leave my application open to a form of XSS attack where they reference as many browser caches as they can within their own "attacker" site with say a link in a phishing email.

Is JavaScript browser caching safe enough to do that without worrying, or are there 'cache scrubbing' type attacks which make it inadvisable? Also, if it is unsafe by default, is there a way to make it safe? If it is or can be made safe it will save me tons of work but don't want to utilize unsafe methods of storing "sensitive" user information (the only sensitive thing it gives away are API credentials which can be used to perform CRUD operations against the service the API is hosted from, which themselves could contain actually sensitive information).

  • 1
    I think JavaScript browser caching is safe, because it doesn't get saved/stored to the server. Individual users can fundamentally hack themselves as much as they want to using the console. And there can be issues with data leakage. But these exist outside the browser as much as within it. XSS as a threat has to do with controlling/preventing users from adding scripts in other's browsers (primarily through script injection) – ControlAltDel Sep 02 '22 at 19:19
  • @ControlAltDel Ah true, XSS is probably not the right term for it then but I think i got the idea across. Thanks for the clarification! – August Guenther Sep 02 '22 at 19:23
  • 1
    Take a look here https://stackoverflow.com/questions/11760602/safely-storing-sensitive-data-client-side – Richard Sep 02 '22 at 19:23
  • 1
    "*caching the API calls (which contain the users API credentials)*" - you should not be caching the requests but rather the responses. The responses may contain sensitive data, but they should not contain credentials. – Bergi Sep 02 '22 at 23:59

0 Answers0