Security warnings

[DemiMarie]

Proposed changes

Nginx has various security limitations:

• Modules that proxy to upstream servers (HTTP/1.x, FastCGI, uwsgi, SCGI) assume that the upstream server is trusted
• Modules that set headers, trailers, URLs, or request methods do not check that the result is valid.

Checklist

Before creating a PR, run through this checklist and mark each as complete:

• I have read the contributing guidelines.
• I have signed the F5 Contributor License Agreement (CLA).
• If applicable, I have added tests that prove my fix is effective or that my feature works.
• If applicable, I have checked that any relevant tests pass after adding my changes.
• I have updated any relevant documentation (README.md and/or CHANGELOG.md).

[pluknet]

While I generally support the idea to explicitly document a concept of trusted backends (and other similar origins) to address the progressively decreasing entry level, this should be done is a more correct and fine-grained way, avoiding bold / unsubstantiated statements and other FUD.
Also, the nginx reference documentation is not a bug-tracker or Beginner's guide, something more concise should be enough.

I will keep it open in order to not forget to do this properly.

[Zoey2936]

Not sure if this is the right place to report, but since the topic of this PR is similiar: it would be nice if the alias path traversal miss configuration (https://mailman.nginx.org/pipermail/nginx-devel/2023-July/C36V7SJGRTJRN5JOLBCULA3EAFDTHJDJ.html) could be mentioned in the docs. I didn't know about this, which now caused a 10/10 security issue in my project (ZoeyVid/NPMplus#3626)

[pluknet]

Not sure if this is the right place to report, but since the topic of this PR is similiar: it would be nice if the alias path traversal miss configuration (https://mailman.nginx.org/pipermail/nginx-devel/2023-July/C36V7SJGRTJRN5JOLBCULA3EAFDTHJDJ.html) could be mentioned in the docs. I didn't know about this, which now caused a 10/10 security issue in my project (ZoeyVid/NPMplus#3626)

This is a well-known misconfiguration of prefix locations, notably when using together with the alias directive.
It was previously well explained in https://mailman.nginx.org/pipermail/nginx-devel/2023-July/YSJ5EIRYFWXIEZKKC6OXW76XIPMDTW6A.html

As for improving the documentation, IMHO, all the necessary parts are given.
An attentive reader can note an unsafe anti-pattern from the first sentence and example in http://nginx.org/r/alias.
Let me emphasize:

8<-------------------------------------------------
Defines a replacement for the specified location. For example, with the following configuration

location /i/ {
    alias /data/w3/images/;
}

------------------------------------------------->8

The example is intentionally given with a trailing slash as part of best-current practices.
Generally, we avoid introducing anti-patterns in examples, see 268cfb9.

Next, the concept of prefix locations is explained in http://nginx.org/r/location.

8<-------------------------------------------------
Among them, the location with the longest matching prefix is selected and remembered.
------------------------------------------------->8

In your case, location /images/gravatar would match against:
/images/gravatar
/images/gravatar/
/images/gravatarfoo
/images/gravatar..

If this is not intended, the configuration should be adjusted appropriately.

If reading the documentation doesn't make it clear for some reason,
feel free to suggest your wording for the documentation update, e.g. as a note.
Some points that seem obvious may be unclear to a fresh reader.