Sanitization of the text input (e.g. < becomes <, > becomes >, etc). This is automatic/implicit on a lot of modern web frameworks (since text and Html are distinct types and output to a page are treated differently, with text sanitization being implied unless you opt out).
You shouldn't ever be running untrusted JavaScript. Content Security Policy and similar are just extra layers of protection if you mess up.
Not the input, the output. There are some good comments on this thread about the distinction.
Case in point: the owner altered the vehicle's name using the vehicle's own UI (which is probably not browser based). That input gets stored in the database. Then another system, web-based, wants to display it. If you don't encode the output, you'll be exposed.
Never trust that the input is properly encoded. HTML encode it before display, always.
That would be a good first step, but more importantly making sure any content is rendered in a safe way. In this instance safe means making sure HTML entities are properly encoded and escaped.
The page being discussed is accessed by Tesla garages all over the country (and potentially internationally), creating a web app on an intranet site makes a lot of sense (for single point of update, single point of support, and the ability to run across diverse user devices). Particularly as the raw data always need to come from Tesla's HQ either way.
As to if the same garage machine should also have access to the internet, I cannot speak to that, it depends what else it is being used for (e.g. showing customers Tesla's public facing website for example, accessing third party vendor's inventory systems, research, etc).
No platform is immune from insecure usage. Not desktop software. Not terminal emulators. Not even mobile apps. That's particularly true when the context you're stealing information from is the same as the context you're attempting to run evil code.
I’m saying a network namespace or equivalent should isolate the browser from being able to access external IPs or non-whitelisted IPs, if the browser can also access internal systems.
A separate browser instance should be used for accessing external links, preferably with JIT disabled, with a file system namespace or equivalent disabling access to much of the file system.
