Implementing a secure Content Security Policy (CSP) for NiceGUI web app deployments

[benvc]

I am working on securing a NiceGUI web app deployment against OWASP Top Ten Web Application Security Risks. I am currently implementing a Content Security Policy (CSP) to help secure the app against cross-site scripting (XSS) attacks and I have run into some obstacles that make it difficult to balance security with functionality in NiceGUI. Below is some example code to help guide the discussion followed by a list of obstacles I have encountered in the implementation and some ideas about how these could be overcome. If anyone has good ideas about how to overcome any of these obstacles in the current version of NiceGUI, please share your thoughts. I am also interested in thoughts on how NiceGUI could be updated to facilitate implementing this type of security without impacting features and functionality.

Below is an example middleware implementation that uses the secure.py Python library to set a CSP header consistent with OWASP recommendations on all responses in NiceGUI (or FastAPI or Starlette). This is a strict CSP that would essentially prevent an app from loading cross-origin resources as well as inline scripts and styles with unknown origins. Implementing a strict CSP like this one would likely break most, if not all, NiceGUI deployments. I am not suggesting that a CSP needs to be this strict in order to be secure but just illustrating a simple implementation.

from fastapi import Request
from nicegui import app
from secure import ContentSecurityPolicy, Secure

csp = (
    ContentSecurityPolicy()
    .default_src("'self'")
    .script_src("'self'")
    .style_src("'self'")
    .connect_src("'self'")
    .object_src("'none'")
    .base_uri("'self'")
    .frame_ancestors("'none'")
    .form_action("'self'")
    .upgrade_insecure_requests()
)

secure_response_headers = Secure(csp=csp)

async def add_secure_response_headers(request: Request, call_next):
    response = await call_next(request)
    await secure_response_headers.set_headers_async(response)
    return response

app.middleware("http")(add_secure_response_headers)

Reasonable adjustments to the policy above could include allowing trusted locations as script sources, using nonce directives, etc.

I think the following NiceGUI implementation details present the most complexity when attempting to modify a CSP in order to secure a NiceGUI web app deployment (I understand that listed potential solutions may not be trivial or practical to implement but hopefully they are good discussion starters).

Inline scripts and styles

Obstacle:
NiceGUI renders inline scripts and styles that require CSP to include 'unsafe-inline' values in the script-src and style-src directives for a NiceGUI page to render properly. This opens up a broad XSS attack vector.

Potential solution 1:
Change NiceGUI page render code to render inline script and style elements to script and style elements with src attributes pointing to files with same-site origins, which would satisfy the 'self' value in the script-src and style-src CSP directives.

Potential solution 2:
Change NiceGUI page render code to include a nonce attribute on all script and style elements with a per response server-generated, difficult to guess random value. It is important to use some kind of templating to insert nonces (since programmatically inserting them on all script tags may inadvertently include them in attacker injected scripts). Also requires implementing a function to retrieve the generated nonces so they can be included in the CSP header.

Vue.js template compiler

Obstacle:
I have not looked at this in great detail, so I apologize if I am off the mark here. I think that NiceGUI is implementing the Vue.js template compiler to dynamically generate components. The template compiler utilizes new Function() to convert templates into executable JavaScript render functions, which creates security vulnerabilities similar to those associated with the eval() API. This requires the CSP to include 'unsafe-eval' in the script-src directive for a NiceGUI page to render properly and opens up a broad XSS attack vector.

Potential solution 1: Pre-compile templates and use the runtime-only build of Vue.js which excludes the template compiler. This may not be practical depending on NiceGUI implementation details.

Potential solution 2: Define components using render functions instead of templates to avoid runtime compilation. This may not be trivial to implement.

Potential solution 3: Look at incorporating the Trusted Types API with polyfill to mitigate XSS vulnerabilities and enable use of more secure CSP directives. I don't have experience with this approach yet and can't guess on implementation difficulty.

In the near term, it would be generally helpful to those deploying NiceGUI apps in a secure context if security best practices were included in the documentation, something like Vue.js security best practices. This would certainly help with implementing CSP if it made clear whether or not there are ways to use NiceGUI without the vulnerabilities exposed by inline script and style injection or the Vue.js template compiler (for example, perhaps it is only a subset of components that require these NiceGUI implementation details).

Looking forward to the discussion on this topic and hope it is helpful in the continued development of NiceGUI.

[rodja]

Thanks for this great opening to add CSP to NiceGUI. Here are my thoughts on the raised major topics:

Inline scripts and styles

I very much prefer to include a nonce attribute. Loading via src extra urls is not only slower but might also be harder to implement. Generating and setting a nonce for the script tag in index.html should be straight forward. And by exposing the nonce via ui.context.nonce or similar, dynamic Inline css from components, ui.add_css and possible css/js additions via ui.add_html/ui.add_head_html could also be marked with the nonce fairly easy. Anyone interested in creating a PR?

Vue.js template compiler

None of the three options you suggested are very appealing in my opinion. We mainly need the Vue.js template compiler for

• elements use of template strings
• user defined, dynamic slot-templates
• dynamic property evaluation

Also, we use some libraries which have new Function() calls internally (Echarts, Plotly, AGGrid, JSONEditor,...).

Maybe we need to look deeper into the Trusted Types as our only option?

Security Documentation

Yes! We should have something like that. I guess that should be something we should do in parallel with the development of the two obstacles we need to tackle first. Right?

[benvc]

I don't know enough about NiceGUI internals for a proper PR, but here is some example code for applying a dynamic CSP header with a nonce. NiceGUI may want to incorporate two aspects of this into their implementation (applying the CSP header middleware itself should be left to those developing apps with NiceGUI as they will need to control the specifics of all other CSP directives):

• for each HTTP request / response, generating the cryptographically secure nonce with adequate entropy
• for each HTTP request / response, including the nonce in some state variable accessible to code that creates components generating inline scripts and style (example below uses request.state attribute Starlette, and by extension FastAPI, makes available for arbitrary state data).

from secrets import token_urlsafe

from fastapi import Request
from nicegui import app
from secure import ContentSecurityPolicy, Secure


async def add_csp_response_header(request: Request, call_next):
    """
    Add Content Security Policy (CSP) response header with random nonce for each response.
    CSP is a security feature that helps protect against cross-site scripting (XSS) attacks.
    It restricts the sources from which scripts and styles can be loaded.
    """
    response = await call_next(request)

    # NiceGUI generates random nonce for each response
    nonce = token_urlsafe(32)

    # NiceGUI stores nonce to be used in inline scripts and styles
    # i.e. Starlette request.state attribute https://www.starlette.io/requests/#other-state
    request.state.csp_nonce = nonce

    # App developer using NiceGUI adds CSP header to response including nonce and other custom directives
    # minimal example, for info on secure policy directives see https://owasp.org/www-community/controls/Content_Security_Policy
    csp = (
        ContentSecurityPolicy()
        .script_src("'self'", f"'nonce-{nonce}'")
        .style_src("'self'", f"'nonce-{nonce}'")
    )
    csp_response_header = Secure(csp=csp)
    await csp_response_header.set_headers_async(response)
    return response


app.middleware("http")(add_csp_response_header)

This just leaves the hard(er) part of determining the best way to expose the nonce for inclusion anywhere that app developers using NiceGUI are instantiating components that will generate related inline scripts or styles. I am pretty new to NiceGUI, so I don't know the best way to determine which components will be accompanied by inline scripts or styles (and, as a result, which component instantiation methods would require some sort of "include nonce" configuration parameter to generate the required "nonce" attribute). Also, there may be inline scripts and styles that are generated in the header or body that are not directly related to a particular component, perhaps resulting from combination of components or page context, and there would need to be some way to include the nonce for those as well.

It is tempting to come up with some global config that just automatically includes the nonce attribute on all inline scripts and styles generated by NiceGUI, and it may be possible to do it in a secure way but something like this would have to be implemented very carefully so as not to simply apply nonce attributes into any and all inline scripts or styles including maliciously injected ones.

When I get some time, I will look into the Trusted Types API to see if I can help advance the discussion on that front as well.