Reputation: 961
While fiddling with WCF fault contracts, I was hoping I could reuse my custom Exception inheritance tree as TDetail in my Faults. After getting this to work, I started thinking this through (yes, after doing the work, you know that's the best time to think). And I noticed that the client gets the full stacktrace of the exceptions that are serialized as TDetail.
Now I was thinking that this is the exact reason you don't turn on <servicedebug includeExceptionDetailInFaults="true" />
. But I'm not sure. Would it be a security risk for me to use my exceptions as TDetail? And what are my other options?
Upvotes: 1
Views: 326
Reputation: 839
Depends on who are the consumers of your service. If lets say you are opening it to the outside world, it would not be a good idea to pass these details to the clients of the service, because it gives the consumers of the service an idea about things that could cause a security breach. But if you are lets say using it internally and managed well and you want them to some how be able to do some thing with these details, then its your call, cause at the end of the day its probably behind a firewall not open to the outside world and on a network being controlled by an administrator Im guessing.
Upvotes: 0
Reputation: 1863
As mentioned, it can be a security risk in that it reveals more about your internal systems to the outside world. However, the TDetail can be anything, so you could create new exception options that keep the messages and interesting exception information youd like to keep but clears out secured data like the stack trace and then serializes just those parts you approve of to the client.
Upvotes: 1
Reputation: 6293
Exposing stack trace isn't so big security risc but potentialy can give atacker more information aboute you system (database, libs, etc. ). So in my opinion you should turn details of in production environment but they are a great help when debugging.
Upvotes: 1