"Cache Assets" option caches responses with cookies

[ssddanbrown]

Checklist

• Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
  • Yes
• Are you sure you're not using someone else's docker image?
  • Yes
• Have you searched for similar issues (both open and closed)?
  • Yes

Describe the bug

Hello,
I believe that the "Cache Assets" is currently caching responses which contain cookies, which isn't something I'd expect by default (at least without warning).
This can lead to responses with session cookies being cached and provided back to other users.
This is something I discovered when supporting a user of my software, who was using nginx-proxy-manager with this option enabled, who found that their login accounts would change somewhat randomly.

I believe this is down to the following proxy_ignore_headers line:

nginx-proxy-manager/docker/rootfs/etc/nginx/conf.d/include/assets.conf

Line 9 in 79d28f0

proxy_ignore_headers Set-Cookie Cache-Control Expires X-Accel-Expires;

When reading initially, I thought that this line was specifically preventing responses with Set-Cookie headers from being cached, but this is not the case.
From what I understand, by default nginx won't cache proxy responses with the Set-Cookie field following the guidance here:

If the header includes the “Set-Cookie” field, such a response will not be cached.

The proxy_ignore_headers option then tells nginx to ignore certain headers for its own internal processing. It does not ignore responses that have these headers as I initially assumed when reading.
In this case, since Set-Cookie is used with this option, it's essentially telling nginx to ignore its default behaviour and allow Set-Cookie responses to be cached.

Testing/Replication

I tested this via a simple PHP script to set a cookie:

Script

<?php

$expires = time()+60*60*24*30;
$dateTime = str_replace(':', '-', date(DATE_ATOM));
$requestPath = $_SERVER["REQUEST_URI"];

setcookie("beans", $dateTime, $expires);

echo ("hello from {$requestPath}; Cookie value: {$dateTime}; Expires: " . $expires);

Then I ran that script with php -S 0.0.0.0:8000 server.php, then created a proxy server to that host, with the "Cache Assets" option enabled. A request to /cat.png would then become cached.

Then I removed Set-Cookie from line 9 of the /etc/nginx/conf.d/include/assets.conf, restarted the container, then tested again via a different endpoint (/dog.png) and observed that the response was no longer cached.

Nginx Proxy Manager Version
v2.12.3

Expected behavior

Responses with cookies applied should not be cached (by default).

Operating System
Fedora 41

---

Note: I did think about reporting this as a security issue, since it can interplay with user sessions via cookies, but I couldn't find any security reporting details or contact details, but instead found past similar requests for security contact details go unanswered. Should be a niche scenario anyway (instances with cache option active, where assets could be served with relevant cookies).

[Adiack06]

I have had the same issue while using book-stack (the software @ssddanbrown makes) with this nginx proxy setting enabled

[faulpeltz]

@ssddanbrown This causes problems with self-hosted GitLab instances as well, because some assets like user-profile images contain a cookie header (which they probably shouldn't), causing intermittent session takeover across accounts

I think NPM should, in a standard setting, never cache Set-Cookie headers or aggressively override caching based on file extension alone, instead I suggest maybe have a "standard" "force/aggressive" cache mode if you really need it?