If I'm not mistaken, in webapps there are a lot of potential attack vectors, such as http header spoofing and what not, which are not there in typical rich-client desktop applications, such as WPF applications. To add a bit more motivation to my question, I have the feeling that most security related issues I come across in news and blog articles concern webapps. Me being a desktop developer with 0 experience in web-development, I began to wonder: are rich-client apps inherently more secure than webapps?

For example, can a simple desktop app with a classic login (username + password), a database (that resides on a remote server) that only contains usernames with hashed passwords (and salt), without any other "authentication" process, be considered less vulnerable overall (lets say towards the most common types of attacks) than a webapp that does the same?

Perhaps to make my question more focussed, based on the comments I received: What are some of the main security concerns for each type? Are there any potential vulnerabilities that exist in one but definitely aren't worrysome to the other?

Please note that I am not considering scenarios where one uses technologies of the other. For example, the desktop app should do what it does without any usage of web technologies or protocols (such as HTTP).

  • 2
    Each application type has their own types of potential vulnerabilities.
    – schroeder
    Aug 29 '20 at 12:28
  • 2
    Ok, one of the crucial concepts to keep in mind whenever you say the word "secure" is the question "secure from what?". Is a rock more secure than a cat? Well, it depends on what you are talking about, the context, and what threats you are worried about.
    – schroeder
    Aug 29 '20 at 12:49
  • 1
    For instance: security.stackexchange.com/questions/84486/…
    – schroeder
    Aug 29 '20 at 12:51
  • Good point! I am having a hard time describing what "secure" means myself. Essentially, I am thinking about protection against "imitating" a legitimate user by modifying http traffic, SQL injection etc., basically anything that makes webapps vulnerable Aug 29 '20 at 13:09
  • You can also have SQLi in desktop apps, too, if you use SQL. It's not that one is inherently more vulnerable than another, but rather that one might be easier to introduce certain types of vulnerabilities in one than another. A web app and a desktop app also have radically different threats to worry about. If you hand a SQL database to be installed on the desktop, you can forget about that database being secure. You don't even need SQLi. You've handed the db to the user. Desktop apps can also be exploited to get root access on the desktop.
    – schroeder
    Aug 29 '20 at 13:21

It's probably impossible to fully quantify the different threats to each program type. My initial reaction, though, is "No". It's often easier to attack web apps - they're more often exposed and easy to find - but that doesn't mean much to a motivated attacker and most of the most-famous worms and other highly-damaging malware targeted desktop apps or other non-web software.

The following lists are not comprehensive; I just wanted to illustrate some of the many, many factors.

Some security advantages of desktop apps:

  • Do not necessarily to accept traffic from the Internet directly, although some do. Those that don't usually require some victim actions (like opening a file).
  • More likely to act as a client (making requests and getting responses) than a site (which is hosted by a server). Assuming the app's server is not malicious, this makes it harder for an attacker to attack the connection.
  • Unless using a webview, immune to client-side web vulnerabilities such as XSS or CSRF. Even if using a webview, usually the risk is reduced because you don't browse arbitrary sites with the webview.
  • Many systems support various hardening options (NX/DEP, ASLR, etc.) that make successful exploitation of some attacks hard.
  • Many systems support customizable sandboxing (including containers, etc.) to allow running the code with the least privileges it needs (unfortunately, this requires developer or possibly user action that is rarely taken).

Some security disadvantages of desktop apps:

  • Most do not run sandboxed (though sandboxes are becoming more common); compromising one can take over the entire computer and possibly local network, or at least everything on it that the user has access to (think ransomware, etc.).
  • Much more likely to be written in native code or call into native libraries with attacker-controlled data, which means more risk of memory corruption vulnerabilities (buffer overflow, use-after-free, etc.).
  • Plenty of room for confusion around the multi-user machine model (what directories or other objects are safe to use, what permissions should be set on privileged components, etc.).

Some security advantages of web apps:

  • Browsers automatically provide a lot of security features that are not necessarily present elsewhere, like the same-origin policy and sandboxed system access.
  • Web apps are easy to update when an issue is found, and then everybody immediately gets the patched version.
  • While a compromised web app might compromise a large number of users, the damage to each user is likely less because each web app is isolated from others so most of your computer use is unaffected (note: this is less true if you share passwords across sites!).
  • Browsers include support for secure communications (HTTPS) and data parsing (HTML Form formats including MIME, JSON) making it less likely people try to implement their own protocols / parsers and risk messing it up.
  • Since the server is generally doing only a well-defined list of tasks and does them autonomously, it's relatively easy to restrict access to it (except on TCP 80/443) and sandbox it to limit both its attack surface and blast radius.

Some security disadvantages of web apps:

  • Common, well-known and easily-weaponized attack patterns (XSS, CSRF, etc.) that are often easy to find by anybody with a browser (so, everybody).
  • Browser differences in security-relevant behaviors and feature support means mitigations might cover some users but not others (less of a problem now than before, but some people still use IE, even version 10 or older).
  • Confusing standards (e.g. CORS) and common misconfigurations (bad TLS suites, SAML/OAuth handling, XML entity handling) mean there's a lot you might have to know to set up a web app securely (many potential threats).
  • High-value targets (compromise one app or service, potentially hit a ton of users and/or get lots of valuable data).

Not the answer you're looking for? Browse other questions tagged or ask your own question.