id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	uname	nginx_version
1810	"Complex UX - Configuration Pitfalls (""Passing uncontrolled requests to PHP"")"	yanosz@…		"'''Is: Problematic User-Experience (UX) for administrators'''

https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#passing-uncontrolled-requests-to-php lists common pitfalls, that could result in remote code execution (e.g. https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#passing-uncontrolled-requests-to-php). Referring to the OWASP-Project (OWASP Top-10 2017) ""Security Misconfiguration"" and ""Broken Access Control"" are among the most critical web application security risks.

Again, regarding ""Passing uncontrolled requests to PHP"" the docs are proposing 4-different, working configurations without explicitly recommended a single one. Some configurations are problematic in certain setups (""The one caveat is that this workaround prevents you from using try_files to avoid PATH_INFO attacks. See Passing Uncontrolled Requests to PHP above for alternative ways to mitigate these attacks."" - Paragraph ""Using the try_files $uri directive with alias"").

In addition, regarding ""Proxy Everything"", it is not intuitive  clear to me, in what way the example for ""Also GOOD"" applies the protections needed. (E.g. what happens, if somebody reorders the two location directives by accident?)

'''Should: Better UX / Usable Security '''

By design, nginx's configuration should avoid known pitfalls. Regarding 
""Passing uncontrolled requests to PHP"" this could - for example - result in deprecating, fastcgi_pass and introducing   fastcgi_pass_harmful and fastcgi_pass_checked, with the first one having the old fastcgi_pass effect and fastcgi_pass_checked applying protection according to one of the 4 ways proposed.

In addition, the documentation should recommend one way explicitly, that ""just works"" in 99% of all cases.  Referencing others is fine, but users need to be guided.

In addition, nginx should refuse to start, if commonly known, insecure patterns exists in the configuration. Staring using a additional command line parameter should be possible, though"	enhancement	closed	major		nginx-core	1.17.x	wontfix			"Linux www2 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) x86_64 GNU/Linux
"	"nginx version: nginx/1.10.3
"