"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:

https://github.com/NginxProxyManager/nginx-proxy-manager/blob/79d28f03d035114b80dcd04845306ecb98175074/docker/rootfs/etc/nginx/conf.d/include/assets.conf#L9

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?

[francescocaponio]

As a reference, I'm attaching the link to gitlab's issue.

Please note that the issue happens even if the Cache Assets option is disabled from the UI.

[ssddanbrown]

Please note that the issue happens even if the Cache Assets option is disabled from the UI.

@francescocaponio Have you verified that from a (relatively) clean state? From when I opened this, it looks like the relevant nginx config was only at play with the setting enabled, so would be surprised unless there's some other level of caching config, or caching layer in play, or retained session after toggling the caching option.

[francescocaponio]

We noticed it on our instance, but also user alexhoisl on the gitlab issue tracker is experiencing the same problem with cache disabled.

[ssddanbrown]

@francescocaponio They confirm, in their next comment, that information was wrong and later confirm that they no longer have the issue with caching disabled. Since this applies to cookies those wrong cookies will remain in browsers for a while, so even after changing the setting existing sessions/cookies could need to expire or be deleted/invalidated otherwise wrong logins (or other problems caused by mixed cookies) may persist.

[francescocaponio]

Now I see it, sorry, but I read it fast.

We should do a more consistent test here too. In our environment we have two instances of npm, one from external ips and one from internal ones. They were configured differently for the caching option. Let me check it better, but it's quite difficult to make it happen in a reliable way.

[ahoisl]

Sorry for the confusion! Yes, after disabling "Cache Assets" the GitLab authentication problem was fixed.

[github-actions[bot]]

Issue is now considered stale. If you want to keep it open, please comment :+1:

[ssddanbrown]

👍 I think it's worth keeping open @github-actions bot!