form-action 'self' in nginx CSP breaks SAML HTTP-POST binding redirects

[mmguero]

Summary

The CSP hardening added to the nginx proxy layer (as part of the third-party security assessment remediation) includes:

# Block clickjacking and restrict base/form targets; does not affect script/style execution
add_header Content-Security-Policy "frame-ancestors 'self'; base-uri 'self'; form-action 'self';" always;
# Legacy clickjacking fallback for browsers that don't honor CSP frame-ancestors
add_header X-Frame-Options "SAMEORIGIN" always;

A user has reported that form-action 'self' breaks SAML authentication. SAML's HTTP-POST binding relies on the browser auto-submitting a form to the IdP's origin (and back to our ACS endpoint on return) — form-action 'self' blocks that cross-origin form submission by design. This is the policy working as intended, just incompatible with POST-binding SSO.

Root cause

Not a bug in the directive, but a conflict between strict form-action and any auth flow (SAML, and potentially others) that relies on cross-origin form POSTs.

Fix

We shouldn't disable the whole CSP block via a blanket env var, because frame-ancestors and base-uri are unrelated to this issue and should stay locked down unconditionally.

Instead, we should scope the fix to form-action only:

1. Add an env var, e.g. NGINX_CSP_FORM_ACTION_EXTRA representing a space-separated list of additional allowed origins (the SAML IdP base URL(s)).
2. Template the CSP header at container start instead of a static add_header line:

add_header Content-Security-Policy "frame-ancestors 'self'; base-uri 'self'; form-action 'self' ${form_action_extra};" always;
add_header X-Frame-Options "SAMEORIGIN" always;

3. Document usage: users running SAML set this to their IdP's exact origin (e.g. https://idp.example.com).

Before merging

• Confirm via browser console CSP violation report that form-action is actually the blocking directive (not connect-src or something else layered on top of a JS/meta-refresh redirect). The violation report names the directive explicitly.
• Confirm whether the IdP redirect is genuinely cross-origin POST-binding, or proxied through our own domain first (in which case the real fix may be elsewhere).

Acceptance criteria

• frame-ancestors 'self' and base-uri 'self' remain hardcoded and unconditional in all deployments
• form-action allows additional origins only when NGINX_CSP_FORM_ACTION_EXTRA is set
• Default behavior (env var unset) is unchanged from current hardened state
• SAML login flow verified working end-to-end with the reporting user's IdP
• Env var documented in README / config docs

[mmguero]

mmguero-dev/Malcolm@237f790

Implemented a scoped fix for this issue.

Rather than disabling the entire Content Security Policy, the existing protections remain enabled unconditionally:

frame-ancestors 'self';
base-uri 'self';

The form-action directive can now be extended with additional trusted form submission targets through a new environment variable:

NGINX_CSP_FORM_ACTION_EXTRA

The value is a space-separated list of CSP source expressions, typically identity provider origins. For example:

NGINX_CSP_FORM_ACTION_EXTRA=https://idp.example.org https://login.example.com

The resulting response header is:

Content-Security-Policy: frame-ancestors 'self'; base-uri 'self'; form-action 'self' https://idp.example.org https://login.example.com;

The origins should not be comma-separated or individually quoted.

The implementation renders the configured value into an nginx variable at container startup:

map $host $form_action_extra {
  default "https://idp.example.org https://login.example.com";
}

The CSP header then references that nginx variable:

add_header Content-Security-Policy "frame-ancestors 'self'; base-uri 'self'; form-action 'self' ${form_action_extra};" always;

This keeps same-origin form submissions enabled by default while permitting only the explicitly configured external targets.

I also hardened the nginx template rendering performed by the container entrypoint:

• Boolean values used directly in nginx configuration are normalized to literal true or false.
• Values inserted into quoted nginx configuration strings are rejected if they contain control characters, double quotes, backslashes, or dollar signs.
• envsubst is restricted to an explicit allowlist of expected template variables.
• Rendered files are written to temporary files and moved into place only after successful substitution.
• Environment variables that are only consumed during entrypoint template rendering were removed from nginx_envs.conf; variables read by Lua workers at runtime remain there.

Testing

I verified the emitted CSP header directly with curl:

$ curl -u maltest -skD - -o /dev/null https://malcolm.example.org |
    grep -i '^content-security-policy:'

content-security-policy: frame-ancestors 'self'; base-uri 'self'; form-action 'self' https://idp.example.org https://login.example.com;

I also checked the header on an authenticated API response:

$ curl -u maltest -skL -D - -o /dev/null \
    https://malcolm.example.org/mapi/version |
    grep -iE '^(HTTP/|location:|content-security-policy:)'

HTTP/2 200
content-security-policy: frame-ancestors 'self'; base-uri 'self'; form-action 'self' https://idp.example.org https://login.example.com;

Firefox Developer Tools showed the same header in the response:

frame-ancestors 'self'; base-uri 'self'; form-action 'self' https://idp.example.org https://login.example.com;

I then tested CSP enforcement from the Firefox console. A synthetic form submission to an origin not present in the policy was blocked:

const form = document.createElement("form");
form.method = "POST";
form.action = "https://not-allowed.example.invalid/";
form.target = "_blank";
document.body.appendChild(form);
form.submit();
form.remove();

Content-Security-Policy: The page’s settings blocked the loading of a resource
(form-action) at https://not-allowed.example.invalid/ because it violates the
following directive: “form-action 'self' https://idp.example.org
https://login.example.com”

Repeating the same test with the permitted origin https://idp.example.org caused Firefox to attempt the navigation in a new tab. (The request itself failed because the example hostname was not serving an identity provider, but there was no CSP violation, confirming that the configured origin was allowed.)

I also tested the new entrypoint validation by setting:

NGINX_CSP_FORM_ACTION_EXTRA=https://idp$.example.org

The container correctly failed closed during startup:

NGINX_CSP_FORM_ACTION_EXTRA contains characters unsafe for generated nginx configuration
nginx-proxy exited with code 1

Finally, I verified boolean normalization using:

ARKIME_SSL=1
ROLE_BASED_ACCESS=yes

The generated nginx configuration contained normalized values:

map true $arkime_protocol {
  default https;
  "false" http;
}

map true $capture_service_role {
  default "capture_service";
  "false" "admin";
}

An end-to-end SAML login was not performed because I do not currently have a SAML identity provider available in this test environment. However, the response-header checks and positive/negative browser form-submission tests confirm that nginx emits the configured policy and that Firefox enforces it as intended.