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).
