Idea - Content Security Policy with server generated nonce

Content Security Policy with server generated nonce

New

Frontend (App Interfaces)

Current CSPs rely on allow-listing domains which is difficult to secure, and vulnerable to attackers bypassing the CSP.

As an example, it is currently impossible to implement Google Tag Manager without compromising an Outsystems Content Security Policy, as it requires both the unsafe-inline directive. It also requires allow-listing the www.googletabmanager.com domain which is found to host JSONP endpoints, which also can be used to bypass the CSP.

See: https://csp-evaluator.withgoogle.com/ for a report

The recommended approach is to use server generated nonce tokens in the CSP, and also in the scripts that are allowed to load. These scripts are considered trusted and may in-turn safely load script from other, cross domain sources.

For tag manager, a recommended setup is here https://developers.google.com/tag-platform/security/guides/csp

My suggestion is for Outsystems to support generation of nonces in the CSP headers returned to the client, and allow the front end to load a developer defined script with the same nonce tag. From there we could load any other cross domain resources without needing to weaken the CSP.

For more information, see https://web.dev/articles/strict-csp

28 Aug 2024

Erik Brzozowski

We hit exactly this limitation while implementing Google Tag Manager in a B2C application running on ODC.

GTM requires a CSP nonce that is cryptographically random and unique per request — injected simultaneously into the CSP response header and the HTML. That per-request uniqueness is what makes the nonce effective as an XSS mitigation. ODC only supports static CSP configuration via the Portal, so any nonce configured there is hardcoded and identical across all requests. We could work around this by reading the nonce from a server-side setting and injecting it into script tags at runtime via custom JavaScript — but the CSP header itself remains static and always contains the same value. A static nonce is visible in the HTML source and reusable by an attacker, which defeats its purpose entirely.

We raised this with OutSystems Support. Their formal response confirmed:

- Dynamic nonce support is not available in ODC

- There is no supported workaround

- There is no roadmap ETA for this feature

Our current CSP still enforces a domain allowlist, which provides some baseline protection — but it falls well short of what a properly implemented nonce-based CSP delivers, and a static nonce is a known security anti-pattern that can be flagged in a penetration test.

What we need is for ODC to generate a cryptographically random nonce per request and inject it into both the CSP response header and the rendered HTML automatically — exactly as described in this idea.

We strongly support this request and encourage OutSystems to treat it as a platform security gap, not just a feature addition.

2 days ago