> My point is: The bad example does something, which is extremely
> inefficient but it just works. It has no side effects concerning
> security. All files are parsed by PHP, so no unparsed configuration
> files can leek.
I beg to differ. If there are files that are not supposed to be
interpreted by the PHP interpreter and your config doesn't prevent
that: it's a bad thing. Efficiency, certainly being important, falls
behind security IMO.
> The "good example" only handles requests to the FastCGI instance if
> the file or directory can not be found by nginx. This is clearly not
> the same although the whole intention of the pitfall site is, in my
> eyes, to offer exactly that: A naive, inefficient way to achieve
> things and a professional, tested, reliable and secure way. It's the
> first URL given in Debian's default config and possibly the first
> place a user will look like searching for help.
> Proxying everything is certainly a bad idea; proxying too less is
> disastrous in terms of security. This should be pointed out in the
> wiki in big fat letters. Or better, let's come up with a better
> example of how to proxy a bare minimum.
The problem with that is that it varies from app to app. It's quite
difficult to be "generic". Hence probably that's one of the reasons
why the example in the Pitfalls page is so "uncongenial".
We should opt for a specific example and warn about the pitfalls