in reply to Forgetting your good education
in thread Writing a perl quiz. Need advice.
The purpose of fatalsToBrowser is to provide useful debugging information in the browser. This speeds up development. However it means that if someone finds "unexpected behaviour" in your application, they can use your debugging information to get insight into how your application works, and then use that to fine-tune an attack.
For a common example, suppose that you interface with a database. And, as happens depressingly often, you don't quote a field that shows up in an SQL query. You now suffer from the possibility of an SQL injection attack - someone can enter in anything they want and have it become part of your SQL. If they can figure out the right thing, they can get "interesting results". (Such as downloading your credit card data. Or taking over your database server.)
Now obviously this is much easier if they can find out something about the structure of the query that they are breaking. And something about your database. Which is far, far easier if you provide useful debugging information in the browser. See, for instance, http://www.sensepost.com/misc/SQLinsertion.htm (or many other pages on SQL injection at Google) for how an attacker can use debugging information to keep on escalating an attack until they can get anything they want from your database.
Not publically providing debugging information doesn't fix the bug, but it does make it a lot harder to exploit. It often makes the difference between a minor intrusion and a serious problem.
So how do you do this with minimal impact on your ability to debug? The answer is simple. You make fatalsToBrowser be something that is readily flipped in your code. Preferably either in a configuration variable that differs between production and development, or as something that your standard build process does. That way you get all of the benefits while developing or whenever you need it in production, but without making an attacker's life any easier than it has to be.