JSF+PrimeFaces应用CSP配置疑问：是否可弃用、最优值及官方计划

Great question—let’s break this down step by step, since balancing JSF/PrimeFaces behavior with CSP can feel tricky, especially given the lack of clear examples online.

1. Can we skip CSP entirely because JSF has built-in XSS protection? #

Short answer: Absolutely not. JSF’s default XSS safeguards (like auto-escaping EL expressions) are fantastic for blocking server-side injection risks, but they don’t cover every possible attack vector. CSP adds a critical defense-in-depth layer:

• It stops unauthorized script execution from third-party domains or DOM-based XSS payloads that might slip past server-side checks.
• It prevents accidental loading of malicious resources (e.g., rogue scripts from a compromised CDN).
• Modern security frameworks (like OWASP Top 10) explicitly list CSP as a core control, even with strong server-side protections in place.

2. What’s the optimal CSP configuration for JSF + PrimeFaces? #

The "best" config depends on how strict you want to be vs. how much legacy PrimeFaces functionality you need to support. Here are two practical approaches:

a. Balanced, Compatible Configuration (Most Apps) #

This works with nearly all PrimeFaces versions, minimizes breakage, and still adds meaningful security:

Content-Security-Policy: default-src 'self'; 
                         script-src 'self' 'unsafe-inline' 'unsafe-eval'; 
                         style-src 'self' 'unsafe-inline'; 
                         img-src 'self' data:; 
                         font-src 'self';

• 'unsafe-inline' is necessary because PrimeFaces generates inline scripts/styles for components like dialogs, tabs, and AJAX handlers (though newer versions are cutting back on this).
• 'unsafe-eval' supports components like p:chart (which uses eval for rendering) and some AJAX logic.
• data: in img-src covers PrimeFaces components that render base64-encoded images (e.g., dynamic p:graphicImage content).

b. Strict Configuration (PrimeFaces 8+ + JSF 2.3+) #

If you’re on newer versions, you can ditch 'unsafe-inline' entirely by using nonces (cryptographically random values generated per request):

1. Generate a nonce via a servlet filter or backing bean, store it in the request, and add it to the CSP header:

// Example servlet filter code to generate and attach nonce
String nonce = UUID.randomUUID().toString();
request.setAttribute("cspNonce", nonce);
response.setHeader("Content-Security-Policy", 
    "default-src 'self'; " +
    "script-src 'self' 'nonce-" + nonce + "' 'unsafe-eval'; " +
    "style-src 'self' 'nonce-" + nonce + "'; " +
    "img-src 'self' data:; " +
    "font-src 'self';"
);

2. Configure PrimeFaces to use the nonce in your web.xml:

<context-param>
    <param-name>primefaces.CSP_NONCE</param-name>
    <param-value>#{requestScope.cspNonce}</param-value>
</context-param>

This tells PrimeFaces to include the nonce in all its inline scripts/styles, making them compliant with the strict CSP. For your own custom inline scripts/styles, add the nonce attribute too: <script nonce="#{requestScope.cspNonce}">...</script>

3. Are there plans to simplify CSP implementation for JSF/PrimeFaces? #

Yes! Both teams have recognized the pain points and are actively working on improvements:

• PrimeFaces has been reducing its reliance on inline scripts in recent releases, moving more logic to external .js files.
• PrimeFaces 8+ added native support for nonces and hashes, making strict CSP setups feasible without constant workarounds.
• Future PrimeFaces versions may include built-in filters or context parameters to auto-generate nonces, eliminating the need for custom filter code.
• While JSF spec improvements are slower, the community is pushing for better native CSP integration in upcoming versions.

内容的提问来源于stack exchange，提问作者mittal