public interface CspSupport
The browser Content Security Policy mechanism includes script-src directives
such as 'unsafe-eval' and 'unsafe-inline' that restrict the use of
eval(), new Function(), inline event handlers, and dynamic script
loading. These restrictions were introduced to mitigate injection attacks in applications
where untrusted user input is carelessly concatenated into executable code — a class
of vulnerability that arises primarily from naive application-level coding practices, not
from the use of mature, security-audited frameworks.
Smart GWT does not currently support running under a CSP policy that disables
unsafe-eval or unsafe-inline. This is a deliberate architectural
decision, not an oversight. The sections below explain why.
CSP's script-src directives were designed to protect against a specific
threat: an attacker who can inject a string into an HTML page such that it is executed as
code. This threat is real when application developers use patterns like:
element.innerHTML = "<img onerror='steal(document.cookie)' src=x>";
eval("processData(" + userInput + ")");
In a Smart GWT application, developers do not write code like this. The framework manages all DOM rendering, event handling, and server communication through controlled internal pathways. User-supplied data flows through typed DataSource fields, validated both client- and server-side, and is never interpolated into executable contexts. The attack surface that CSP was designed to close simply does not exist in a properly built Smart GWT application.
Smart GWT has been deployed by major banks, defense contractors, intelligence agencies, and financial institutions worldwide for over two decades, passing hundreds of independent security audits, with no history of meaningful injection exploits against the framework itself. This real-world security track record is far more significant than compliance with a header that addresses an inapplicable threat model.
Smart GWT is not unusual in this regard. The more capable and feature-rich a JavaScript framework is, the more likely it is to rely on dynamic code generation for core functionality. Among major frameworks:
unsafe-eval. Avoiding it
requires a precompilation build step that eliminates
runtime template compilation entirely, meaning
templates cannot be composed or modified dynamically
at runtime.unsafe-eval. The AOT
(Ahead-Of-Time) mode avoids it, but at the cost of
eliminating dynamic template compilation, requiring a
heavyweight precompilation build, and producing larger
deployment bundles. Many Angular libraries and
plugins still assume JIT availability.Frameworks that do claim full CSP support tend to be either much simpler (providing no comparable dynamic features), or they achieve compatibility only through a precompilation step that sacrifices the ability to compose, modify, or generate UI definitions at runtime. Every framework that has undertaken CSP compatibility documents resulting performance penalties, increased bundle sizes, and reduced runtime capabilities.
Smart GWT uses eval(), new Function(), and related facilities
for their intended purpose: high-performance code generation, powerful dynamic features,
and runtime flexibility. These are not naive uses of dangerous APIs — they are
deliberate architectural choices that deliver significant value. Disabling them would
degrade or eliminate the following capabilities:
User-Defined Formula Fields, Summary Fields, and Dynamic Properties
End users can define calculated grid columns using
spreadsheet-like formula expressions (e.g.,
A + B * 0.1) and summary templates (e.g.,
#{lastName}, #{firstName}). These are
compiled into JavaScript functions for evaluation on
every grid row.
Dynamic Properties
use the same mechanism: a component property value can
be computed from data values and other application
context via a UserFormula or
UserSummary expression — for example,
deriving a grid column's
title from a formula like
ruleScope.currentUser.region. Without
dynamic code generation, none of these user-defined
function capabilities would be available.
Server Communication Performance
Smart GWT uses an optimized pseudo-JSON serialization format for server responses that
supports JavaScript Date constructors and other non-strict-JSON constructs. Deserializing
these responses falls back to eval() when JSON.parse() cannot
handle the format. Under CSP restrictions, every server response would need to use strict
JSON, requiring additional server-side serialization overhead and client-side date
reconstruction, measurably slowing all DataSource operations.
The Smart GWT Developer Console is a powerful debugging tool that allows developers to evaluate arbitrary JavaScript expressions against live application state, inspect component trees, watch DataSource traffic, and profile performance. All of this depends on dynamic code evaluation. Without it, the single most important tool for diagnosing issues in running Smart GWT applications would be non-functional.
Reify (Low Code Visual Builder)
Reify enables visual, drag-and-drop application construction that generates Smart GWT
component trees from declarative screen definitions. Screens loaded from the server
(via RPCManager.loadScreen() and RPCManager.createScreen()) are instantiated
by evaluating their JavaScript representation at runtime. CSP restrictions would make it
impossible to load or create screens dynamically, defeating the purpose of the tool.
AI Integration and
AI-Generated Components
Smart GWT's AI features allow natural-language operations like filtering grids, adding
calculated columns, and generating entire data-bound components from user descriptions.
The AI engine produces JavaScript component definitions that must be dynamically evaluated
to create live UI. Chain-of-Thought prompt templates also use dynamic expression
evaluation for variable interpolation. These features are fundamentally incompatible with
CSP eval restrictions.
The FileLoader and Dynamic Module Loading
FileLoader supports background loading and caching of JavaScript and CSS resources
to optimize application startup time. The scriptInclude
RPC transport enables cross-domain communication
by dynamically
injecting <script> tags. Both mechanisms are restricted under strict
CSP policies.
Internal Performance Optimizations
Throughout the framework, new Function() is used to generate optimized
accessor functions, criteria evaluators, and serialization routines. These dynamically
compiled functions are significantly faster than interpreted alternatives because the
JavaScript engine can JIT-compile them with full optimization. Replacing them with
generic, data-driven alternatives would produce measurably slower execution across many
hot code paths, including DataSource filtering, record validation, grid rendering, and
sort operations.
Rather than crippling the framework to comply with a policy that addresses an inapplicable threat, organizations concerned about application-level code quality have several effective alternatives:
eval() and similar patterns in
application-level code, which is where injection risks actually originate."use strict" prevents certain unsafe
patterns at the language level.TypeScript support.These approaches target the actual source of risk — application code written by developers who may be inexperienced with security — without degrading the capabilities of battle-tested framework code.
Smart GWT does not plan to add CSP unsafe-eval compatibility to its
roadmap, because doing so would mean permanently maintaining a crippled, slower variant
of the framework with no genuine security benefit.
However, for customers who face an intractable organizational requirement for CSP
compliance, we offer the possibility of creating a restricted mode through our
Feature
Sponsorship
program. Such an effort would produce
a version of the framework that can run under unsafe-eval restrictions, with
the following caveats:
scriptInclude
transport, and others) would be unavailable
in this mode.If your organization has this requirement, contact Isomorphic Software to discuss scope and sponsorship terms.