Duplicate HTTP security headers in v1.12.1 when following official Nginx documentation

[iRaphi05]

Current Behavior

Since the release of v1.12.1, the Panel includes a new SetSecurityHeaders middleware that injects several security headers (X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Referrer-Policy) via PHP.

However, users following the official Nginx documentation for Pterodactyl already have these headers defined in their Nginx configuration. Because Nginx's add_header directive does not check for existing headers sent by FastCGI/PHP, this results in duplicate headers being sent to the browser:

x-frame-options: DENY
x-frame-options: DENY
x-content-type-options: nosniff
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-xss-protection: 1; mode=block

Additionally, a conflict occurs with the Referrer-Policy, where the middleware enforces no-referrer-when-downgrade, potentially overriding more restrictive user-defined policies like same-origin.

Expected Behavior

The Panel should not send duplicate headers if they are already managed by the webserver. Ideally, the official Nginx documentation should be updated to reflect these changes, or the middleware should be made configurable via environment variables to allow administrators to manage headers at the webserver/proxy level (e.g., Nginx, Caddy, or Cloudflare).

Steps to Reproduce

1. Update the Panel to version v1.12.1.

2. Ensure the Nginx configuration is set up according to the official Pterodactyl documentation (including the add_header lines).

3. Inspect the response headers of the Panel using curl -I https://your-panel-domain.com or Browser Developer Tools.

4. Observe the duplicate entries for the security headers.

Panel Version

1.12.1

Wings Version

1.12.1

Games and/or Eggs Affected

N/A (Global Panel issue)

Docker Image

N/A

Error Logs

N/A (This is a configuration/logic conflict, not a crash/error)

Is there an existing issue for this?

• I have searched the existing issues before opening this issue. I understand that maintainers may close this issue without communication if I have not provided sufficient information.

[DaneEveritt]

There is really no winning here, so I think we just roll back and don't include any headers already present in the webserver configurations. I prefer the application setting the headers just for configuration and tweaking sake, but seeing as there is a decade of nginx configuration out there for this software that probably doesn't make sense at this point in time.

If there are headers not present in the configurations we suggest using for nginx we can keep them here.