We are evaluating WeWeb for a next project and we would like to know about the necessity (or not) of use the CSP directives unsafe-eval and unsafe-inline.
Will WeWeb work with strict secure CSP using vue runtime-only?
Is there any docs talking about that?
Thank you.
Dear WeWeb team @Joyce ,
I hope this message finds you well.
I am writing to express my concerns regarding the security protocols implemented within WeWeb. I apologize if my previous communication was unclear, and I aim to provide further clarification on my inquiry.
The company I represent is currently engaged in the development of a web system for a multinational corporation, catering to a substantial user base on a daily basis. As part of our efforts to enhance this system, we have contemplated exploring no-code solutions, particularly for the frontend aspects.
However, a critical requirement has arisen pertaining to the content-security-policy script-src directive. Specifically, our system necessitates the exclusion of âunsafe-evalâ and âunsafe-inlineâ without nonce. Presently, our system relies on the ExtJS framework, wherein even the latest iteration (version 7.7) necessitates the allowance of these flags. Consequently, we are compelled to reconsider our frontend framework selection.
Our research has led us to discover that Vue.js could potentially fulfill our security prerequisites, provided we utilize the vue.runtime.js instead of the full vue.js version. Moreover, it appears that employing Vite over Webpack is optimal for achieving this objective.
Given that WeWeb leverages Vue.js and offers the capability to export code, we have contemplated whether exporting and hosting the code on our servers could facilitate compliance with our security standards, thereby alleviating concerns regarding WeWebâs servers.
Hence, I am reaching out to ascertain the feasibility of running a WeWeb application without necessitating âunsafe-evalâ and âunsafe-inlineâ directives, or any other unsafe directives, within the CSP headers.
Your prompt response regarding this matter would be greatly appreciated, as it will significantly influence our decision-making process moving forward.
Thank you for your attention to this matter.
Warm regards.
Hi @ethraza 
Sorry I missed your initial post and thanks for taking the time to follow up and clarify! I have to confess I read the title and didnât click on it because I didnât understand it 
Let me ask the tech team about this and get back to you 
Yes you can set custom headers like X-Content-Security-Policy, but you do this via your hosting provider. Weweb offers reasonable âtable stakesâ hosting but if you want a higher level of control or more advanced hosting features, your best play is to self-host. Weweb offers self-hosting for paid plans on an annual schedule (not monthly).
Members worked on a number of those migrations in State Change office hours in the last six months. The project to self-host is hours of work, not days, and it introduces a build step that takes minutes per transfer (from weweb editor to your self-hosted environment). Its not completely transparent, but in the spectrum of initiatives, pretty painless.
Hi @ethraza,
WeWeb needs eval() and to work.
I am not completly sure to understand what you want but we cannot remove this as it is part of some core features of WeWeb like being able to type some javascript anywhere in the application.
Allow me to try to explain our security requirements in detail.
Our clientâs security team has requested the removal of âunsafe-evalâ and âunsafe-inlineâ directives from the CSP header to enhance protection against XSS attacks, among other vulnerabilities.
When the âContent-Security-Policyâ header includes something like âdefault-src âselfâ âunsafe-evalâ âunsafe-inlineââ, it permits the execution of JavaScript code from unsafe sources, thereby increasing the risk of XSS attacks. This encompasses functions like eval(), among others. You can find more information on this topic here (Strict CSP - Content Security Policy) and here (https://content-security-policy.com) and here (https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy). Additionally, Vue.js documentation (Installation â Vue.js) indicates that Vue.js will work with strict CSP when using the runtime build instead of the full build.
Considering that WeWeb utilizes Vue.js, I presume that the code generated and exported by WeWeb can function with the Vue.js runtime-only. However, the lack of documentation, posts, or videos on this matter concerning WeWeb leaves me uncertain.
We acknowledge that developers may not always be well-versed in security matters. I, myself, am continuously learning. However, given that our development team is not extensively experienced with Vue.js and WeWeb frameworks, we seek assurance from WeWebâs technical and security teams that our security requirements can be met with the exported WeWeb code. This clarity is essential for us to invest further time in learning and adopting these technologies.
For example:
https://community.weweb.io/ has an A grade (Scan results for community.weweb.io) - CSP here is Ok
https://crm-template.weweb.io/ has an F grade (Scan results for crm-template.weweb.io) - CSP here is not ok, besides other security flaws
Thank you for taking the time to understand our needs and for your efforts in providing clarification.
Best regards.
To deepen our understanding and provide a comprehensive response, letâs explore the topic of âunsafe-evalâ in scripts.
As per the Content Security Policy (CSP) specification, there is no provision for permitting unsafe script constructions using ânonce/hashâ tokens, akin to what can be achieved with âunsafe-inlineâ.
CSP classifies certain constructs as eval-constructs, which include:
Itâs noteworthy that setTimeout() and setInterval() are categorized as âevalâ solely when the callback function is passed as a string. If the callback is an anonymous function or a âfunction by name,â they do not fall under the eval category. In such scenarios, removing eval can be accomplished without altering the scriptâs logic.
For further insights into this subject, please refer to the following source: â Content Security Policy: unsafe-eval and blocking of eval(), setTimeout(), setInterval(), new Function(), setImmediate(), execScript() and Blazor WASM - which of these considered as unsafe eval expressions in JavaScript?.
I trust this explanation provides the clarity you seek regarding whether the WeWeb library can be compatible with strict CSP.
Best regards.
Hi @ethraza,
Iâm sorry but I donât think an app built with WeWeb can comply with your tough requirements atm as one of our core feature rely on eval. Youâre free to download an exported project sample on our website and try to host it with every headers you need and check how it goes.
However I think we can improve on multiple others area here. We plan to discuss about how to make some of these headers configurable per project basis (Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options).
Have a nice day!
Thank you for your response. We recognize the value of WeWeb as a robust tool; however, at the present moment, its functionalities do not align with our specific requirements. We will continue to closely monitor WeWebâs development and hope that with future updates, the platform can evolve to better meet the needs of our corporate system.
We appreciate your ongoing support.
Best regards.