I am working to build a system that requires an interface to control existing data and add new ones. It's really nothing complex, just a few objects related to users, organisation etc.

The problem is that my boss wants this admin interface to be built in native desktop client but I think it's creating unecessary overhead.

We are a small company and I am pretty much the only developer with near zero dekstop app dev experience excluding some swing I did back in Uni.

We will be using IP whitelisting and will allocate a dedicated server for both solutions but here are the differences in our thought.

Please advise me which is better. Is it worth the pain to build/maintain a dekstop app?

Boss' opinions

  • Desktop is safer since it stops random people from manipulating our data if they don't have the program

  • Rival company is employing this method. Currently they are no.1 in the market

My thoughts

  • Hoping for security by building a desktop app is security through obscurity at best

  • Unless we use sockets, it's gonna use HTTP anyways essentially making it the same as a web app, just on a different port

  • Web app is much easier to develop and doesnt have as much compatibility issues

  • Even employing OTP is easier here

  • IMHO it is not. The cookies in your bosses browser are no more or less secure than anything the desktop app stores. Maybe using a browser installation only for the admin app will satify your bosses paranoia?
    – marstato
    Oct 19, 2016 at 22:34
  • lol that browser installation may be a good middle point thx :)
    – yhware
    Oct 20, 2016 at 0:01
  • 3
    Use Electron and put an HTML/JavaScript application on the desktop Oct 20, 2016 at 0:47

3 Answers 3


There isn't really a security difference if both desktop app and browser app are properly built. Yet, I would definitely lean towards the browser app because you get several features "for free" (e.g. PKI for HTTPS).

All security measures that are present in modern browsers can be built into a desktop app alright. The problem is that that would likely require more development effort and allow for more places where mistakes can happen.

Let's have some fun with counterarguments now:

Desktop is safer since it stops random people from manipulating our data if they don't have the program

LOL! < sarcasm >Yeah, reverse engineering does not exist, and obscurity can prevent eavesdropping < / sarcasm >.

With the amount of computing power we have today security through obscurity is getting less and less possible. A couple of megabytes of traffic dumped into a statistical model can construct a specification of how data is sent. And, unless you will never repeat the same commands to the admin interface, you cannot escape from a statistical model by using obscurity only.

Your only option is encryption. Which means you will need to implement full TLS. And by full I mean TLS (you could use openssl for this part) and HSTS, and a revocation path for compromised certs, and a CSP would be good as well. And all that carefully enough to not make mistakes. Cryptography does not allow space for coding mistakes.

Rival company is employing this method. Currently they are no.1 in the market

MasterCard still uses mainframes to process (some of their) Chipcard data. And still send different clearing files in distinct EBCDIC flavours. Shall we all use mainframes for payments?

You can still make mistakes in the web app and make it worse than a desktop app. But there is a lot of documentation about securing web apps.

There are also good frameworks to build desktop apps that come bundled with TLS communication. Using one of those (Python paramiko and Microsoft WIF come to my mind) is an option but see the next section:

Extra point

The Achilles heel (in terms of security) of desktop apps is their dependency tree. A desktop app will require dozens of libraries, which may have security bugs. You will need to keep an eye on the CVEs for all libraries. And, if one of the libraries turns out to not be very popular, there will not be many bughunters looking at it.

(That's also true with unpopular JavaScript libraries though)

And finally come the desktop app updates. You found that your desktop app is vulnerable to something and patched it. Good! But now you need to distribute the new version to everyone using it, including that guy who is working from home for the past two months. OK, you may send him an email with the new installer. But wait, can't the email be tampered with? Or even in a more mundane point, can you be sure that he will update his app?

A web app is much easier to update.

  • 1
    Man this is so much more than I expected. Thanks so much for explaining all the points in detail. I mean I argued for the web app idea but didn't really have a concrete technical explanation for it but now I do lol. Cheers ;)
    – yhware
    Oct 20, 2016 at 0:00

It depends on how the application is build, protected and used. A typical problem for web based administration is that it is used from inside the same browser which is also used to surf the open internet. This makes it possible to use the browser as a trampoline to attack internal systems from outside.

Such cross-origin attacks possible with the browser are especially Cross Site Request Forgery (CSRF) and Cross Site Scripting (XSS) attacks but also DNS rebinding. Web based administration interfaces are often insufficient protected against such attacks which means that these attack vectors get successfully used against routers or even industry devices.

Desktop applications by themselves don't have these kind of problems. Of course if the desktop application is just employing a browser interface in the background and is using HTTP(s) for communication you might get the same problems back.


Aside from what was already said, you should consider how your application is going to talk to whatever it's managing.

If that's a database, and you go with a plain desktop application, it means exposing your database server to connections from all your potential client computers. Keep in mind that anyone can see your connection strings. You will have to rely on your database's security features for authentication and authorization. This is a huge surface area to secure.

For a web application, only your web server needs to know how to talk to your database. Everything else is hidden away neatly behind a HTTP facade, and you have a much greater degree of control over what your clients can do.

Of course you could do both - expose some kind of web API that your client applications will talk to. But now you have two applications to maintain - the API and the client itself. Unless you expect to have more consumers of your API, you're much better off just doing the UI as a web application too.


You must log in to answer this question.

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