Just like any other factor, the amount of risk you can handle will vary by project. Subsequently, the amount of security testing required will differ. Here are some things that might get you thinking about your application:
Logins (user ID and password). On the web this may include cookies and on client/server it could include .INI files that store user information.
What is the user allowed to do once she is in the application? Does the system properly manage the allowed functions?
Security holes in the application
Can the user accomplish a disallowed function by using a backdoor or a workaround?
For example, Customer Service Reps may not be able to process a Return for a customer (perhaps these have to be done by the Team Supervisor user role.) However, the Customer Service Reps found out that the return can be processed by entering a new order for the item with a negative number in the quantity field. This credits the customer's account, so the customer is happy. However, this does not perform the necessary inventory updates.
Altered client code
If security is a high-risk concern, then you might consider validating data from clients on the server before blindly processing it.
For example, the IRS would not simply trust the data from client machines of individual tax payers, even if the client application had all the proper edits, because then tax fraud would be as simple as re-writing the client application. In this case, the IRS would need to validate the data from the client, to ensure integrity.
[This message has been edited by testgeek (edited 04-22-2002).]