The problem is that the exact same debugging output that helps you figure out how to make a program work how you want it to can help an attacker to make it not work in the way that he wants it to.
A security hole generally starts off as a way to get your code to do something that it shouldn't. This often means that your code will die. In order to refine this into an attack, the attacker needs to figure out what they are doing that causes your code to misbehave, and needs to figure out how to make your code misbehave in the way that they want. You do not want to assist them in that, which means that you don't want to hand out debugging information.
The example that I point people to is the "SQL injection attack". In this case people don't properly escape parameters to SQL, and an attacker can then get custom SQL into your database. With debugging output, the attacker can probe to find out what your (now broken) SQL looks like, make it become something that the database will accept, convince the database to cough up information about what it looks like (which database it is is a good thing), and then convince it to cough up its data. (Credit card numbers are a favorite.)
If you don't provide debugging output, all of this is still possible, but it becomes incredibly harder to do.
In reply to Re: Carp: Fatals to my email
by tilly
in thread Carp: Fatals to my email
by Andre_br
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |