Shifting blame

+1. Excellent article.

Clearly, when building a fast development framework you have every temptation to have options that trade security for ease-of-development. After many years of fighting with register_globals in PHP apps (ie: Moodle) my take is that, if you need those options in your framework, they MUST default to off, and they MUST carry a scary name.

The name matters. It has to trigger two conversations:"Why does this app / toolkit required that we set development_unsafe_hackme_register_globals=Yes?" and "does your patch/feature need development_pwnme=Yes to work?".

And eventually "I don't think I want to use this patch / toolkit / app, if we have to enable developer_unsafe_mode=Yes I fear the developers are not security conscious".

PHP has various such configurations... register_globals got fixed, but "display_errors", with that meek name, it still defaults to sending full error output to the client, which can leak a lot of data to a potential attacker.