Security headers are dropped on non-2xx responses for custom apps

[Nanogabi]

Hello,

I am running a custom app on Cloudron 10.0.5 and noticed that three security headers are missing from any response that is not a 2xx or 3xx. I believe the reverse proxy strips them and re-adds its own only on successful responses.

What I measured

Running the app locally, outside Cloudron, it emits twelve security headers, identical on every response regardless of status code. Here is a successful response and an authentication failure, both from the same app:

GET /api/health  ->  200 OK
GET /api/me      ->  401 Unauthorized

both carry, byte for byte:
  cross-origin-opener-policy: same-origin
  cross-origin-resource-policy: same-origin
  origin-agent-cluster: ?1
  permissions-policy: camera=(), microphone=(), geolocation=()
  referrer-policy: no-referrer
  strict-transport-security: max-age=15552000; includeSubDomains
  x-content-type-options: nosniff
  x-dns-prefetch-control: off
  x-download-options: noopen
  x-frame-options: DENY
  x-permitted-cross-domain-policies: none
  x-xss-protection: 0

Behind Cloudron, the same two endpoints give:

200 OK    -> nine of the twelve, plus
             Strict-Transport-Security: max-age=63072000
             X-Content-Type-Options: nosniff
             Referrer-Policy: no-referrer

401       -> the same nine, and nothing else

The nine that survive are exactly the ones Cloudron does not manage. The three that disappear are exactly the ones it does. On the 200 they come back with Cloudron's own values and in a different header casing, so they are the proxy's, not the app's.

Two consequences

Error responses reach the browser without HSTS, nosniff or a referrer policy, and an app cannot fix this on its own: whatever it emits is removed the same way.

The HSTS value Cloudron sets is also weaker than the one the app sent. The app sends max-age=15552000; includeSubDomains, and what reaches the client is max-age=63072000 with no includeSubDomains, so subdomain coverage is silently lost.

What I think would fix it

Adding always to the add_header directives in the app nginx configuration, so the headers are emitted on every response and not only on 2xx and 3xx. Preserving the upstream value when the app already sets one would also avoid the downgrade, though the always part is the one that matters to me.

I did not try to work around this by editing the nginx config, since app configs are rewritten on restart and upgrade.

Happy to provide more details or test a fix on my side.

Thanks

[girish]

@nanogabi thanks for the report, it is spot on. I have fixed it for the next release - https://git.cloudron.io/platform/box/-/commit/57ef2c2fd3baf161f45c1402e3526222998e9b6f