Images Not Displaying Due to Content Security Policy (CSP) Restrictions

[ruslan-murzag]

Bug description

Images hosted on external URLs are not displaying in Apache Superset due to Content Security Policy (CSP) restrictions. Despite configuring TALISMAN_CONFIG to allow all sources, the browser console still reports CSP violations, specifically blocking image loading from external URLs.

Steps to Reproduce:

1. Configure TALISMAN_CONFIG in superset_config.py with settings to allow all sources:

TALISMAN_CONFIG = {
    "content_security_policy": {
        "default-src": ['*'],
        "img-src": ['*'],
        "worker-src": ['*'],
        "connect-src": ['*'],
        "object-src": ['*'],
        "style-src": ['*'],
        "script-src": ['*'],
    },
    "force_https": False,
    "session_cookie_secure": False,
}

2. Attempt to display an image from an external URL in Superset.

The image should display as configured, following the img-src: '*' directive.

Actual Behavior:

The image does not load, and the browser console shows a CSP error similar to the following:

Refused to load the image 'http://101.30.83.81:9000/images-superset/photo_2024-10-29_13-57-16.jpg' because it violates the following Content Security Policy directive: "img-src 'self' blob: data: https://apachesuperset.gateway.scarf.sh https://static.scarf.sh/".

Impact:

This CSP restriction prevents images hosted on external URLs from being displayed in Superset, limiting the ability to include necessary external visual content.

Request:

An option to fully relax or disable CSP checks specifically for images would provide flexibility, ensuring that Superset can display images hosted on external URLs as intended.

Additional Context:

This issue specifically affects the display of externally hosted images within Superset, which are essential for various dashboards and visualizations.

Screenshots/recordings

Superset version

4.0.2

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

A similar issue was discussed in a closed thread titled Cached thumbnails not showing in browser due to CSP. The solution involved modifying the img-src directive in the Content Security Policy to include blob:, making it "img-src": ["'self'", "data:", "blob:"]. This change allowed cached thumbnails to display correctly. Additionally, this issue was addressed in version 3.0.1 of Superset ^[1].

In your case, it seems that despite setting img-src to '*', the CSP is still enforcing restrictions. This might be due to a misconfiguration or an override elsewhere in the application. It's generally not recommended to use '*' for CSP directives due to security risks, as it allows content from any source, which can expose your application to vulnerabilities like XSS attacks ^[2].

To troubleshoot, ensure that there are no other configurations or middleware that might be overriding your CSP settings. Additionally, consider specifying trusted domains explicitly in the img-src directive instead of using '*' to maintain security while allowing necessary external images.

To continue talking to Dosu, mention @dosu.

[mistercrunch]

The fact that you have a log explicitly stating Refused to load the image 'http://101.30.83.81:9000/images-superset/photo_2024-10-29_13-57-16.jpg' because it violates the following Content Security Policy directive: "img-src 'self' blob: data: https://apachesuperset.gateway.scarf.sh https://static.scarf.sh/". seems to be pointing to the default config.TALISMAN_CONFIG being in effect (or maybe not the default config, but one that references scarf.sh) and doesn't match the shared TALISMAN_CONFIG that you think should be in effect.

If would suggest double checking that your config file is properly found and loaded.

[ruslan-murzag]

@mistercrunch I considered that and ran the flask CLI in the worker container to retrieve the TALISMAN_CONFIG variable. Here’s the code I used:

from flask import current_app
print(current_app.config.get("TALISMAN_CONFIG"))

This returned the same configuration I had defined in the config file. Is this an appropriate way to verify the TALISMAN_CONFIG, or would you recommend a different method?

[mistercrunch]

Seems like a fair way to validate the configuration. In that context, do you still get the scarf.sh-related log/error messages? Where could that be coming from if you TALISMAN_CONFIG is not referencing it? A zombie/competing process?

There's a lot of different ways to confirm or double check that the endpoint you are hitting is aligned with the configuration / process you think you are running. Do you still get an error/warning after killing all processes (trying to ensure it's not a zombie or other process) or just no answer as expected? Could you add or alter an exsiting endpoint to serve the app.config.get("TALISMAN_CONFIG")?

[rusackas]

Does it work without brackets, e.g. 'img-src': '*',?

[ruslan-murzag]

Hello @mistercrunch @rusackas, I found a solution, though it seems unusual. To display images, I need to modify two configurations:

• TALISMAN_CONFIG
• TALISMAN_DEV_CONFIG

However, I’m running docker-compose-image-tag.yml, which indicates a production setup, not a development one.

[mistercrunch]

All of our docker compose setups, including docker-compose-image-tag.yml, are NOT recommended for production use.

From https://superset.apache.org/docs/installation/docker-compose/

On top of what is described there, there was a challenge around segmentation while supporting dev AND prod use cases within docker-compose semantics, where there was a lot of conditionality in docker-compose (if dev then do_this else do_something_else) which could lead to confusion and security issues. Because of that we decided to recommend helm/k8s/minikube for prod use cases, where we can make sure all the conditions and configurations point to prod/secure images and configurations.

[ruslan-murzag]

@mistercrunch ok i got it.