Lots of Content Security Policy errors
Closed this issue · 5 comments
Im not sure if this is due to recent browser versions, but for both the Redoc and Swagger UI pages I'm having issues. Neither will load in Chrome, and only Redoc will load in Firefox. Here are the console errors:
Redoc in Chrome:
SearchWorker.worker.ts:5 Refused to create a worker from 'blob:https://localhost-core/4c437f09-96dd-4adf-a282-f7cd85221a42' because it violates the following Content Security Policy directive: "script-src 'self'". Note that 'worker-src' was not explicitly set, so 'script-src' is used as a fallback.
Failed to construct 'Worker': Access to the script at 'blob:https://localhost-core/4c437f09-96dd-4adf-a282-f7cd85221a42' is denied by the document's Content Security Policy.
Swagger UI in Chrome:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-7LFgTyTwypFqRNwknDs4bBXRSqR6QY7uIOSKAtjoLKE='), or a nonce ('nonce-...') is required to enable inline execution.
Redoc in Firefox:
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). onloadwff.js:71:799505
Content Security Policy: The page’s settings blocked the loading of a resource at eval (“script-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). utils.js:35:9
Content Security Policy: The page’s settings blocked the loading of a resource at eval (“script-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at blob:https://localhost-core/4c1fd9a7-44f6-4b2b-a83a-72bda549fda5 (“script-src”).
Content Security Policy: The report URI (about:blank) should be an HTTP or HTTPS URI.
Content Security Policy: The page’s settings observed the loading of a resource at blob:https://localhost-core/4c1fd9a7-44f6-4b2b-a83a-72bda549fda5 (“worker-src”). A CSP report is being sent.
Swagger UI in Firefor:
Content Security Policy: The page’s settings blocked the loading of a resource at eval (“script-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). utils.js:35:9
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). onloadwff.js:71:799505
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). swaggerui:33:1
Content Security Policy: The page’s settings blocked the loading of a resource at eval (“script-src”).
I was able to solve the issues by including a middleware that adds the appropriate CSP policies for the OAPI docs routes.
I'm not sure if the CSP for these pages needs to be too strict, so I left it pretty lax. Obviously it could be configured to be more specific to the resource type.
const openapiCSP = (req, res, next) => {
res.set({ 'Content-Security-Policy': "default-src * 'self' 'unsafe-inline' 'unsafe-eval' blob: data:"});
next();
};
app.use('/api/redoc', openapiCSP, openapi.redoc);
app.use('/api/swaggerui', openapiCSP, openapi.swaggerui);
This might be something worth adding into the library itself though.
Hm, I actually would prefer those libraries to handle that, since it is entirely in their domain of control. Could it be that we are outdated and need to update those packages? If that is the case an update PR would be most welcome.
Im not so familiar with the libraries being used, but I agree with trying to implement this at the highest level. Would those libraries support setting CSP policies though? Seems like something that needs to be handled at the server level.
It looks like the swagger-parser
package is pretty far behind (as well as a couple others)
How would an update PR work? Are there autmated tests?
There are automated tests, so you would just make a branch, then run npm update swagger-parser --latest
and commit the changes in package.json
. Submit that as a PR. Even with automated tests, I typically will also run them locally to do a manual check before publishing. I also typically fire up a server and check the UI if there are changes to those packages which provide the UI.
Closing this in favor of the new PR.