We wrote a simple .NET (C#) desktop application in Wpf. We also used WIF (Windows Identity Framework) to get a list of claims for the authenticated user. Some examples are:

  • CanOverrideSalesAmount
  • CanAddContact
  • etc.

This works fine and all, the client seems very protected. But, when I was debugging the application it occurred to me that all of the authorization is happening on the client side. A devious person could use a tool such as Snoop to hook into the application and make changes to the domain model that s/he isn't supposed to do.

We thought about moving the authorization checks on the property setters, but even that isn't good enough because when we serialize the object graph to send over the wire, the serialized data can be altered (far fetched, but still possible).

It seems to me that the only true way to protect my object graph is to have it only reside on the server and to have the client make calls to update it, but that seems like such an overkill. Is there a better way to handle this situation? I want our application to be as secure as possible.

  • Only allow authorized clients to write to the server, with authorization checks being performed on the server.
    – Wilbert
    Sep 10, 2014 at 13:18
  • 2
    @Wilbert: I don't think that such a generalized comment actually helps the OP.
    – myermian
    Sep 10, 2014 at 13:21
  • @m-y But the problem seems to be that all communication coming from a client is trusted. That's bad; not sure it warrants a full answer though, because it's such a basic and obvious statement. However, detailing methods for client-server security seems out of scope for the question.
    – Wilbert
    Sep 10, 2014 at 14:48
  • 1
    Does your app connect to the server over the Internet, or an internal LAN? Sep 10, 2014 at 16:00
  • 1
    You should change the phrase "secure as possible" to "reasonably secure". You don't want nor can afford "as secure as possible". Sep 11, 2014 at 1:48

2 Answers 2


The problem with authorization checks only on the client side is that ultimately an attacker can mimick the behaviour of your application. Robert Harvey argues that it's unlikely for your users to debug the compiled application or to look at the network traffic. It very well may be.

The problem is that it's not rocket science to find out what's going on. And if somebody breaches the security, you may never know, because to the server, everything looks like the regular traffic.

So, the answer is you may try to protect your application by obfuscating it and by encrypting the traffic to the server, but this just raises the bar for a successful breach. Videogame and movie producing companies invest serious effort into developing protection for the software or the content on an untrusted device, but you can see these protections being circumvented quite soon. Running the security-critical part on a trusted computer (like a server) scales much better in terms of effort vs. security.

  • and not just the user, but you also make yourself vulnerable for man in the middle attacks.
    – jwenting
    Sep 22, 2014 at 7:42

Firstly, you should sign the assembly so users cannot tamper with it - Microsoft signs and secures its assemblies in the GAC to prevent hackers tampering with them. You should do the same.

That prevents someone from modifying your assembly using some binary editor, though you will also have to cater for them replacing your assembly completely. Ensure you obfuscate your assembly to make decompliation harder.

You also have to secure the communications channel to the server, or anyone could install wireshark to inspect the packets being sent and then replicate the auth sequence with their own, slight, modifications. You see this occurring all the time on naively written game servers, some people suddenly acquire more game resources because they've spoofed the network messages to tell the server they've "paid" for a massive boost, honest. (and such flash-style games tend not to be written by people familiar with enterprise security).

Network security is quite simple in this day of SSL comms.

You can also improve your communications by using a secure token system (eg Kerberos or similar - do not try to roll your own) that is sent with each message to the server to ensure the message is coming from a properly authenticated user. This stops any user from simply replaying messages outside your application.

Its still possible to be hacked after this, but these steps make you reasonably secure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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