For me building interfaces through HTML / JS frameworks is by far easier then any other framework I have tried in the past. It's also not that strange, as by far the most UIs are based on the web nowadays, so the tools are superb (to me).

Sometimes I need a small tool or app that needs access to "native Windows" stuff - like the file system.

So I built a microserver executable. A very lightweight ASP.NET App (Minimal Web API) where I can build my interface in HTML and JS and communicate with XHR calls for things like "ProcessFiles" or read XXX.

The user launches the daemon and the interface can simply be installed by going to the localhost URL and launch a PWA in their favorite browser.

Note I don't want to use Electron, because I don't like that every app is running a full instance of Chromium on their own, with their won bugfixes, updates etc.

The daemon on itself is SUPER lightweight.

Some examples of these tools:

  • an alternative to File Explorer that I'm working on.
  • a State Machine Editor for my Unity projects.

Of course the whole "web server" in combination with i.e. a File Explorer sounds like a terrible idea from a security perspective.

One thing I do is enforce that the XHR call is coming from and otherwise hard crash. Also it is of course on a "strange port" so I assume this is normally blocked by firewalls.

But not sure if this can be worked around by potential hackers.

  • How risky is this approach in general?
  • Are there any other simple things I can easily do to protect it from ever being abused?


Leave for now out that there are new features to also natively read with the OS, I want to focus on the things above.

1 Answer 1


First of all, there are better ways to do what you're attempting. Electron isn't the only platform for web-based content in a desktop app, and its main advantage is just portability; since you're presumably fine with being Windows-specific, that's not even an advantage for you. Outside of Electron, you have HTML-based Window Store apps, HTML-based desktop apps (via embedding the browser control, classically ieframe but these days it's based on Edge, and thus Chrome). There's even the vintage HTA, which is reliant on the IE engine but is intended for exactly this use case: writing desktop apps using HTML and JS (or VBS, because IE). These options all update the browser control with the OS, so no need to worry about updating anything but your own app logic as needed.

Now, as to your actual question. There's a number of security risks with this design. First of all, all the usual webapp security stuff applies. You need to be secure against XSS, CSRF, clickjacking, and so forth. Note that just blocking XHRs from external sites is not necessarily sufficient, as there are ways to send cross-origin requests without XHR (or fetch). If you're using authentication, you need to be secure against session fixation and session hijacking attacks, flawed password handling, and so on.

If you are not using authentication, you have even more problems. Such an app design makes it trivial to bypass one of the most important OS-level security boundaries, the user (or, more accurately, security principal) boundary, because there's no way for the server to know who the client is. Any user or service on your machine can detect and open an HTTP connection to your server, and send requests to access your local file system and so on. Even if the machine is strictly single-user, you're still enabling sandbox escapes or at least EoP; a sandboxed app - even very tight ones, like the browser sandbox - can still usually access local network sockets without restriction; it's possible to block this but only by blocking all network access, which approximately no app sandbox does.

Finally, there's impersonation-of-the-server risk. Apps running as other users, or in sandboxes, can also spin up their own server, including on the same port your app uses (if your server isn't running already, or if they make it crash first). A malicious server can then capture any inputs from the legitimate user, and/or spoof arbitrary responses to requests. Authenticating the server is possible; that's one of the things TLS (HTTPS) does, though by default it only does it by domain name (or IP) so you'd have to create and trust your own certificate and ensure nobody else could either access its private key nor create their own alternate trusted cert.

I really can't recommend this approach. The server-side programming isn't going to be any easier than doing the same in a desktop app - probably harder, actually - and even granting that you know web front-end programming already, there are modern desktop front-end toolkits that are similar enough (even without using an embedded browser control or HTA) that you'd be better off using one. You'll save yourself from a bunch of web-based and browser-based security risks and hassle, and evade the worst of the desktop app security risks by default too (unless you're doing weird things with ACLs).

  • Intel Driver & Support Assistant uses this approach. Any idea how are they keeping it secure?
    – defalt
    Jan 15 at 10:45
  • Thanks for your extended answer. Just to be clear - this is a low risk environment - I am not releasing this into the wild.
    – Dirk Boer
    Jan 15 at 19:15
  • I do wonder - all these other apps probably communicate through postMessage - as I think XHR and postmessage are the only two options to communicate with anything outside the web. Besides the XHR issues - does postmessage not have the exact same problems? What prevents an Electron app from being spoofed?
    – Dirk Boer
    Jan 15 at 19:17
  • The app is btw without authentication. There is no information that can be found that cant be found through File Explorer. Another thing that I wonder - any app installed on my machine - why would it go through the effort of going through my custom app while it could access the file system itself? Doesn't anything malicious on my machine already mean that all the bytes are exposed?
    – Dirk Boer
    Jan 15 at 19:21
  • Electron and similar avoid being spoofed at the server by not having a server; they don't need to communicate between their front- and back-ends. With that said, there are communication options besides XHR and window messaging; anything from normal GET/POST navigation requests (which a script can make by submitting a form) to websockets. Window messaging only works within a given browser/app, but supports origin-based authentication.
    – CBHacking
    Jan 16 at 3:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .