If there are secrets in your client, you're toast

Programs that communicate over a network to a central server tend to have some type of authentication and access control. That's great, but I've seen several implementations that have no real security, only the appearance of it. Such software usually fits into one of two categories:

1. Client-side security. Programs with this problem rely entirely on the client to check access controls. The absence of checks on the server side means that anybody can bypass the authentication or authorization by throwing together their own client that talks to the server directly, issuing whatever commands the user feels like. Moving the security into the server will probably be a large undertaking for the developers, but it's absolutely essential.
2. Client-held secrets. By "client-held" I mean "burned into the client program." This is a distinct issue from problem #1, though programs with the first often have the second too. Some developers think that obfuscation (to make, say, a string not visibly appear in the EXE) will sufficiently protect any sensitive configuration/information. It won't. A sufficiently determined user can get access to any data that flows through a program running under their own local security context. (Try creating a dump file of a running program and then inspecting that.) This issue also covers "encryption" algorithms that rely on the secrecy of the algorithm to be secure. To remedy this, I suggest using asymmetric-key cryptography and well-known algorithms.