nginx - content security policy CSP

[DRO34]

Hello, can you please tell me the proper policy syntax for the content security policy in nginx? the CSP..

I am not sure what proxcenter requires to fully load

I have tried these both so far. They both produce white pages dont fully load content.

"default-src 'self'; script-src 'self'; style-src 'self'; font-src 'self'; img-src 'self' data:; connect-src 'self'; frame-ancestors 'none';" always;

"default-src 'self'; script-src 'self'; style-src 'self'; font-src 'self'; img-src 'self' data:; connect-src 'self'; frame-ancestors 'none'; object-src 'none'; base-uri 'self';" always;

This works but obviously way less secure

"default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob: wss: https:;" always;

Can you please confirm best policy to get full functionality but also the most secure? Thanks

Here is an example of the white page.
With CSP line commented out, page loads fine or the basic line presented above it works.

[adminsyspro]

Hi @DRO34, thanks for the detailed report (the screenshots help a lot).

Why your strict policies show a white page

The blank page comes down to one thing: Next.js cannot hydrate.

• script-src 'self' blocks the inline bootstrap / RSC streaming scripts that Next.js emits (self.__next_f.push(...)). With those blocked, React never hydrates and you get the white screen you saw.
• style-src 'self' blocks the MUI/Emotion runtime <style> tags and the Google Fonts stylesheet, so even when it does render it would be unstyled.

Your third policy works because it allows everything, but it is far too loose. Below is a tight policy that allows exactly what ProxCenter loads at runtime and nothing else.

Recommended policy (paste-ready)

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com data:; img-src 'self' data: blob: https://*.tile.openstreetmap.org https://*.basemaps.cartocdn.com https://flagcdn.com; connect-src 'self' https://nominatim.openstreetmap.org https://api.github.com; worker-src 'self' blob:; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none';" always;

What each addition is for

Directive	Why it is needed
script-src 'unsafe-inline'	Next.js inline hydration scripts, plus the inline scripts in the noVNC and SPICE console.html pages
style-src 'unsafe-inline'	MUI/Emotion inject <style> tags at runtime
style-src https://fonts.googleapis.com	Google Fonts stylesheet (imported in the global CSS)
font-src https://fonts.gstatic.com data:	The actual Google font files (woff2), served from gstatic
img-src https://*.tile.openstreetmap.org https://*.basemaps.cartocdn.com	Map tiles for the Topology map and the datacenter map
img-src https://flagcdn.com	Country flags on the maps
img-src data: blob:	Console live-preview thumbnails, plus PNG / Excel exports
connect-src https://nominatim.openstreetmap.org	Reverse geocoding when you add or edit a connection with coordinates
connect-src https://api.github.com	Release notes in the About dialog

A few important notes:

• Consoles: the VNC, SPICE and serial consoles all connect over wss:// to the same origin (everything is proxied through your reverse proxy, there is no direct browser-to-node connection), so connect-src 'self' already covers them. If a console ever fails to open on an older browser, add your explicit origin, for example wss://proxcenter.example.com, to connect-src.
• frame-ancestors 'none' is safe to keep: consoles open in popup windows / new tabs, never in an iframe, so this will not break them. It also gives you clickjacking protection.
• No 'unsafe-eval' is required in production. If you ever see an eval violation, you are looking at a next dev build (hot-reload uses eval); the standalone production image does not.

The one honest caveat

script-src 'unsafe-inline' is the only real relaxation here, and at the moment it is unavoidable with a proxy-only CSP. Next.js emits inline bootstrap scripts and the app does not yet send a per-request nonce, so neither a nonce nor a hash can replace 'unsafe-inline' from nginx alone. Removing it cleanly would require nonce-based CSP support inside the app itself, which is a code change on our side rather than something you can do in nginx. It is on the radar.

Roll it out safely

Deploy it as report-only first, so nothing breaks while you watch for violations:

add_header Content-Security-Policy-Report-Only "...same value as above..." always;

Then open the browser DevTools Console and exercise the consoles, the Topology and datacenter maps, and the About dialog. Any blocked resource is logged with the exact directive to adjust. Once the report-only run is clean, switch the header back to the enforcing Content-Security-Policy name.

Let me know if anything still gets blocked and paste the violation line, happy to refine.

[DRO34]

Thank you for detailed info. One thing, i used x-frame DENY are you saying i must use sameorigin? or when you say same origin it is in a different context? im going to test this now.

[DRO34]

That works, thank you! and i am still usign x-frame DENY. Also, the unsafe-inline is that required for the console? I know that can be a weak point.

[adminsyspro]

@DRO34 Glad it works. Two good questions.

X-Frame-Options: DENY vs SAMEORIGIN

Keep DENY, it is the right choice. My "same origin" note referred to a different thing: where the consoles open their WebSocket (back to the same domain ProxCenter is served from), which is governed by connect-src, not by X-Frame-Options.

X-Frame-Options controls who may embed ProxCenter inside an <iframe> (clickjacking protection). ProxCenter never needs to be framed: the consoles open as popup windows or new tabs, and nothing in the UI embeds the app in an iframe. So DENY is safe and is the strongest setting. You do not need SAMEORIGIN.

For reference, the frame-ancestors 'none' directive in the CSP is the modern equivalent of X-Frame-Options: DENY, so you now have the same protection in both headers (modern browsers read frame-ancestors, older ones fall back to X-Frame-Options). That is consistent, not a conflict. One cosmetic note: the app already sends X-Frame-Options: SAMEORIGIN itself, so you may end up with two X-Frame-Options headers. If you want it clean, add proxy_hide_header X-Frame-Options; in your location block before re-adding your own DENY.

Is script-src 'unsafe-inline' required for the console?

Partly, but it is not specific to the console. Two things both need it:

1. The console pages (/novnc/console.html and /spice/console.html) carry their connection logic in an inline <script> block, so those pages need 'unsafe-inline'.
2. More importantly, every page of the main app needs it too: Next.js emits inline bootstrap scripts to hydrate React.

So reworking only the console would not let you drop it, the main app would still require it. The only clean way to remove it entirely is nonce-based CSP, where the server stamps a per-request nonce that both the Next.js scripts and the console inline scripts carry. That is an app-side change, on our radar.

On the weak-point concern: it is a contained one. With object-src 'none', base-uri 'self' and frame-ancestors 'none' already in your policy, and no 'unsafe-eval', the usual ways inline-script CSP gets abused are blocked. Not the textbook-perfect score until nonces land, but not an open door either.

[DRO34]

Thanks for details. I think I can call this one good. So far so good.

[DRO34]

Just came across this error.. I am assuming it has to do with the nginx block.. Any ideas?

[adminsyspro]

Hi @DRO34, good news: this one is not related to your CSP / nginx setup.

It is the same frontend bug as #397: the backup job Run now action called an endpoint that does not exist, so the browser received the HTML error page and the JSON parser failed on <!DOCTYPE …> (Unexpected token '<'). It would happen with or without a CSP.

Fixed in #398 (merged to main), shipping in the next release. Your CSP policy is fine, nothing to change there. Thanks for flagging it!

[DRO34]

Great. Thanks.

[DRO34]

Looks like this backup error is still there after the update

[adminsyspro]

Hi @DRO34, thanks for the follow-up. Good news: this is not the same bug as before, and the difference is right there in the error text.

On June 9 the error read Unexpected token '<', "<!DOCTYPE …'. That leading <!DOCTYPE is the Next.js HTML page, which is what #398 fixed (a genuinely missing endpoint).

This time it reads Unexpected token '<', "<html> <h"…. A bare <html><head> page with no <!DOCTYPE is not produced by ProxCenter. It is the error page generated by nginx itself, which means the request is failing at your reverse proxy (almost certainly a 502 Bad Gateway or a 504 Gateway Timeout) before it ever reaches the app for a JSON answer.

Why the Backups tab specifically: loading backup jobs makes several sequential Proxmox API calls inside one request (the cluster backup schedule, then storages, nodes, and per-node storage status). On a cluster with slow storage that single request can run long, and if it exceeds nginx's proxy_read_timeout (60s by default) nginx kills it and returns its own 504 HTML page. The other tabs make smaller calls, so they stay fine, which matches what you are seeing.

To confirm and fix, could you grab two things:

1. The actual status code: open DevTools, Network tab, click the Backups tab, find the request to /api/v1/connections/.../backup-jobs, and tell me the status (502 vs 504) and how long it ran before failing.
2. The matching line in your nginx error log (/var/log/nginx/error.log). It will say upstream timed out for a 504, or connect() failed / no live upstreams for a 502.

If it is a 504 (timeout), raising the proxy timeouts on the ProxCenter location block fixes it:

proxy_read_timeout 300s;
proxy_send_timeout 300s;
proxy_connect_timeout 75s;

If it is a 502, the timeouts will not help, the app container itself is the thing to check (is it up, did it restart, docker logs).

On our side: the UI should not have shown you a raw Unexpected token '<' in the first place. It should say "the backend returned HTTP 504". I am hardening the Backups panel so a gateway error surfaces as a clear message instead of that cryptic JSON one. That will not make your backups load (your proxy still has to succeed), but it will point straight at the real status. It will land in a coming release.

Send me the status code and the nginx log line and I will confirm the exact tweak.

[DRO34]

Actually its a 403 message. In my original screenshot the error i was getting was idnetical so it seems my issue has always been this and not the one fixed..

x-frame issue?

[DRO34]

This is also impacting my ability to see any of the backups just in general even from the PBS section itself.. so i guess its all related to the 403 error impacting both.

[adminsyspro]

Hi @DRO34, this is the one. And it is fixable in your nginx, not in ProxCenter.

Your screenshot settles it. The 403 response carries Server: nginx, Content-Type: text/html, Content-Length: 548. That is nginx's own default "403 Forbidden" page (~548 bytes, no <!DOCTYPE>, which is exactly the <html> <h... that the JSON parser chokes on). ProxCenter's API only ever answers in JSON, even on errors, so this request never reached the app. nginx blocked it before it got there.

One thing to clear up: the CSP, X-Frame-Options: DENY and HSTS headers you see on that 403 are there because they are add_header ... always directives, so nginx attaches them to its own error pages too. X-Frame-Options is not the cause here. It only governs iframe embedding and never produces a 403. You can leave it at DENY.

Now, why only the Backups tab and the PBS view, while every other tab works. Those are the only two screens whose request URL contains the word "backup":

• Backups tab: GET /api/v1/connections/<id>/backup-jobs
• PBS section: GET /api/v1/pbs/<id>/backups

Every other tab (Summary, Nodes, Guests, HA) calls URLs with no "backup" in them, and those load fine. That pattern is the tell: somewhere in your nginx config there is a rule that denies any URL containing "backup". It is a very common anti-scanner snippet (it exists to block bots probing for /backup.zip, /backup.sql and friends), something along the lines of:

location ~* backup { deny all; }
# or
if ($request_uri ~* "backup") { return 403; }

It does its job against scanners, but it also catches ProxCenter's legitimate backup-jobs and pbs/.../backups API paths.

To confirm in 5 seconds, grep your nginx error log while reloading the Backups tab:

grep -i backup /var/log/nginx/error.log | tail

A path-deny rule logs "access forbidden by rule". If instead you run ModSecurity or another WAF in front, tell me and check its audit log for the blocking rule ID, the fix is the same idea.

The fix: make that backup-deny rule not apply to ProxCenter. ProxCenter serves its API under /api/, so the cleanest options are either to scope the scanner rule to a literal extension instead of the bare word (for example deny only \.(sql|bak|zip|tar)$), or to ensure your ProxCenter location block does not inherit it. Once "backup" URLs are allowed through to the app, both the Backups tab and the PBS view will load.

On our side: a coming release makes the Backups tab show a clear "backend returned HTTP 403" instead of that cryptic Unexpected token message, so this kind of thing points at the real status straight away. That is cosmetic though, the nginx rule is the actual fix.

Paste the matching error.log line and I will give you the exact edit.

[DRO34]

This returns no results grep -i backup /var/log/nginx/error.log | tail

also, we have crowdsec but there are no blocking rules i am aware of doing this, nothing in the logs either. Is there something specifci you want me to check?

maybe this needs a special rule like that other one we had to fix with the exemption for the chunk size.

[adminsyspro]

Hi @DRO34, the empty error.log is actually a useful clue, not a dead end. It rules things out.

An nginx deny rule always writes access forbidden by rule to error.log. Since nothing showed up there, a classic deny rule is off the table. But a return 403 (in an if, map or location block) is silent in the error log and only appears in the access log, and a WAF like CrowdSec's AppSec layer is silent there too. So we just looked in the one log that wouldn't catch it. Let's look where it does get recorded.

Three quick things, the first is the most decisive:

1. curl the failing URL directly, plus a working one for contrast. In DevTools Network, copy the exact failing request URL (the one to .../backup-jobs or .../pbs/.../backups), then from a shell:

# the failing one
curl -sk -i 'https://YOUR-HOST/api/v1/pbs/REPLACE-ID/backups'
# a working one, for contrast
curl -sk -i 'https://YOUR-HOST/api/v1/connections'

If the first returns that little HTML 403 page while the second returns JSON, that confirms the block happens at the proxy/WAF on the URL itself, before the request ever reaches ProxCenter (ProxCenter only ever answers JSON, even on errors). The footer of the HTML page usually names what produced it (nginx, or CrowdSec), which tells us where to aim.

2. Search the fully merged nginx config for a silent 403 rule:

sudo nginx -T 2>&1 | grep -niE 'return 403|deny|location ~|map |backup|modsec|naxsi|appsec|lua'

nginx -T prints the whole config with every include resolved, so this finds the rule no matter which file it lives in. The matches are just rule lines, no secrets, safe to paste.

3. Check CrowdSec's AppSec layer specifically. A normal IP ban would block all your traffic, not only the backup URLs, so that's not it. But the AppSec/WAF component inspects the URL and can 403 specific paths, and its rules do block paths containing "backup":

sudo cscli decisions list
sudo cscli appsec-configs list
sudo cscli appsec-rules list
sudo cscli alerts list

If appsec-configs/appsec-rules show anything, that is almost certainly the blocker, and the fix is to whitelist ProxCenter's /api/ paths in the AppSec config rather than touching nginx.

Paste back the curl output and whichever of those shows a hit, and I'll give you the exact one-line edit.

On our side, a coming release makes the Backups tab show a clear "backend returned HTTP 403" instead of the cryptic Unexpected token '<', so this kind of upstream block points straight at the real status. That is cosmetic though, the proxy rule is the actual fix.

[DRO34]

I also confirmed, accessing proxcenter inside the network, bypassing Crowdsec, also produces the same 403 error on the backups section. So i would assume this is not crowdsec?

This is the result of the /backup

This is the result of the /connections - This one i would expect to see the unauthorized since i am using SSO and have IP restrictions. so i think this one is ok.

These are the appsec configs

no active decisions
alerts are all IP's not related to mine

[adminsyspro]

Hi @DRO34, your internal test was a good idea, but the response headers settle this, and not where the test assumed.

Look at your two curls. The working /api/v1/connections (401) carries ProxCenter's own headers (Content-Type: application/json, X-Frame-Options: SAMEORIGIN, Permissions-Policy: camera=(), microphone=(), geolocation=()), with nginx's always headers stacked on top, which is why X-Frame-Options appears twice. The failing /...backup-jobs (403) carries none of ProxCenter's headers, only nginx's, with a 146-byte HTML body. ProxCenter stamps those headers on every response, even errors, so their absence means the app never saw this request. And since the 403 still says Server: nginx, your internal route did not bypass nginx, it just reached the same nginx another way.

So nginx answers it and ProxCenter is cleared. What is left is which thing behind nginx decides the 403. Two candidates, and the headers cannot separate them:

1. CrowdSec AppSec. Your appsec-configs list shows generic-rules and virtual-patching enabled, both of which ship backup-file probing signatures. Note: reaching the app from a trusted internal IP only skips IP-reputation banning, not AppSec, which inspects every URL regardless of source. So your test did not rule it out.
2. A plain nginx rule (return 403, or location ~* backup { deny all; }), unrelated to CrowdSec.

Your empty error.log grep eliminates neither: AppSec logs elsewhere, and a bare return 403 logs nothing. The tell is that the only two URLs containing "backup", the Backups tab (/backup-jobs) and the PBS view (/pbs/.../backups), are the only two that break.

Three commands name the culprit:

# 1. Real bypass: hit the container directly, skipping nginx, from the Docker host
curl -ski http://127.0.0.1:<proxcenter-port>/api/v1/pbs/<id>/backups
#    JSON back (a 401 is fine) = ProxCenter cleared, block is at the proxy

# 2. Plain nginx rule? Merged config, includes resolved
sudo nginx -T 2>&1 | grep -niE 'return 403|deny|location ~|backup'

# 3. AppSec? Reload the Backups tab, then
sudo cscli alerts list   # or live: sudo journalctl -u crowdsec -f

Whichever returns a hit is the source, and the fix follows: an AppSec exemption for /api/ if it is (3), or scoping that nginx rule to real backup extensions (e.g. \.(sql|bak|zip|tar)$) instead of the bare word if it is (2). Either way it is a proxy-side exemption, same shape as the static-chunk one you set up before, nothing changes inside ProxCenter. Paste back the hit and I will give you the exact edit.

On our side, a coming release shows "backend returned HTTP 403" instead of the cryptic Unexpected token '<', so next time this points straight at the status. That is cosmetic, the proxy exemption is the real fix.

[DRO34]

1. returns no such file or directory what is the id supposed to be?
2. is blank - nothing returned
3. All the IPs listed here are not from my source IPs.

[adminsyspro]

Your 403 comes from nginx (it says Server: nginx and carries only nginx's headers), and it carries none of the headers ProxCenter stamps on every response, so the request is being blocked before it ever reaches ProxCenter. The only two URLs that fail are the two containing the word "backup". That is the whole story: something in your proxy chain denies "backup" URLs. It is not a ProxCenter bug and cannot be fixed inside the app.

If you want to see that with your own eyes, one command from the Docker host (note the quotes, and the id can be anything):

curl -ski 'http://127.0.0.1:3000/api/v1/pbs/x/backups'

JSON back (even a 401 or 404) confirms ProxCenter answers fine and the block is purely in front of it.

The fix is on the proxy side: allow ProxCenter's /api/ paths through whatever is denying "backup", whether that turns out to be an nginx rule or a CrowdSec/WAF signature. You have full visibility of your own stack, so that is the fastest place to whitelist it. Once "backup" URLs reach the app, both the Backups tab and the PBS view will load.

On our side, a coming release shows "backend returned HTTP 403" instead of the cryptic Unexpected token '<', so an upstream block like this points straight at the real status next time.

[DRO34]

It looks like this is the culprit here then.

location ~* "/(wp-admin|wp-login|xmlrpc|phpmyadmin|pma|adminer|admin/config|.env|.git|.svn|backup|.bak|web.config|composer.json|package.json)" {
deny all;
access_log off;
log_not_found off;
}

[adminsyspro]

That's the one. The bare backup token in that alternation matches any path containing it, so it catches both of ProxCenter's backup endpoints (/api/v1/connections/<id>/backup-jobs and /api/v1/pbs/<id>/backups) on top of the scanner probes it was meant for.

The cleanest fix keeps the rule intact for everything else and just exempts ProxCenter's API. ProxCenter serves all its calls under /api/, and that namespace never serves the files this rule hunts for, so excluding it is safe. One-line change, a negative lookahead at the start of the regex:

location ~* "^(?!/api/).*/(wp-admin|wp-login|xmlrpc|phpmyadmin|pma|adminer|admin/config|\.env|\.git|\.svn|backup|\.bak|web\.config|composer\.json|package\.json)" {
    deny all;
    access_log off;
    log_not_found off;
}

That still blocks /backup.sql, /wp-admin, /.env and the rest everywhere else, but lets /api/... reach the app. Then validate and reload:

sudo nginx -t && sudo systemctl reload nginx

If you would rather not edit the regex, the alternative is a higher-priority location ^~ /api/ { ... } block that proxies to ProxCenter, placed above this one. The ^~ makes nginx skip regex locations for /api/, same effect, just structural instead of a one-liner.

Reload, reopen the Backups tab and the PBS view, and both should load. This is purely a proxy change, nothing in ProxCenter.

[DRO34]

This change fixed it here, still maintains actual backup-file scans.. Now i can see the backups

location ~* "/(wp-admin|wp-login|xmlrpc|phpmyadmin|pma|adminer|admin/config|.env|.git|.svn|.bak|web.config|composer.json|package.json)" {
deny all;
access_log off;
log_not_found off;
}

location ~* "^/(backup|backups)/" {
deny all;
access_log off;
log_not_found off;
}

[adminsyspro]

Perfect ! We can closed the issue ?

[DRO34]

Yes, thank you for help in troubleshooting.