Holy cow, I wrote a book!
When you're developing your debugging code,
don't forget that just because it's only for debugging
doesn't mean that you can forget about security.
I remember one customer who asked (paraphrased)
We have a service, and for testing purposes we want to be
able to connect to this service and extract
the private data that the service is managing,
the data that normally nobody should be allowed to see.
That way, we can compare it against what we think the data should be.
This is just for testing purposes and will not be called during
How do you recommend we do this?
Remember that the bad guys don't care whether
the code you wrote was for normal use or for diagnostic purposes.
If it's there, they will attack it.
The customer went to a lot of effort to protect this internal data,
making sure that none of the service operations disclose it directly,
but then in a haze of "this would make debugging easier",
they lost their heads and added a debugging backdoor that
gives direct access to this data that they had worked so hard to protect.
It doesn't matter how much you protect the front door
if you leave the service entrance wide open.
I have a printer driver that insists on creating a log file
in the root of the drive.
This log file, which is world-readable,
contains, among other things, the URLs of every single web page
I have printed.
If I log on as an administrator and delete the log file,
it just comes back the next time I print a document.
I assume the printer vendor created this log file for diagnostic
purposes, but it also creates a security hole.
Everybody on the system can see the URL of any web page that was
printed by anybody else.