DEV Community

Cover image for Security Options in WebForms Core 2
Elanat Framework
Elanat Framework

Posted on

Security Options in WebForms Core 2

#security #webdev #javascript #webformscore

WebForms Core is a server-driven web technology that allows dynamic client-side actions to be executed directly from structured server responses (INI-style).
Because these commands can alter the DOM, load modules, or invoke JavaScript methods, the framework provides a configurable client-side security layer called Security section in WebFormsOptions.

WebForms Core Security

This object defines what operations are allowed or blocked on the client.
By default, all security flags are disabled (set to false), giving developers full flexibility during local development.
However, for production environments, these settings should be carefully configured to prevent malicious code execution or unauthorized module loading.

Default Configuration 

// Security
WebFormsOptions.DisableEval = false;
WebFormsOptions.DisableAppendJavaScriptTag = false;
WebFormsOptions.DisableLoadModule = false;
WebFormsOptions.UseLoadModulePathOnlyInAcceptedList = false;
WebFormsOptions.LoadModulePathOnlyInAcceptedList = ["math"];
WebFormsOptions.DisableCallMethod = false;
WebFormsOptions.UseCallMethodOnlyInAcceptedList = false;
WebFormsOptions.CallMethodOnlyInAcceptedList = ["alert"];
WebFormsOptions.DisableCallModuleMethod = false;
WebFormsOptions.UseCallModuleMethodOnlyInAcceptedList = false;
WebFormsOptions.CallModuleMethodOnlyInAcceptedList = ["confirm"];
WebFormsOptions.SendChecksum = false;
WebFormsOptions.ChecksumName = "checksum";
Enter fullscreen mode Exit fullscreen mode

This default configuration is fully open, meaning:

  • Any code sent from the server can be evaluated or executed.
  • The client can dynamically load any JavaScript module or function.
  • No checksum is sent or validated for message integrity.

This behavior is suitable only in development — not in production.

Recommended Configuration for Production

In production mode, you should restrict every dynamic behavior and explicitly whitelist the modules or functions that are safe to call:

// Security – Recommended for Production
WebFormsOptions.DisableEval = true;                     // Prevent eval() and dynamic code execution
WebFormsOptions.DisableAppendJavaScriptTag = true;      // Block dynamic <script> insertion

WebFormsOptions.DisableLoadModule = false;              // Allow module loading, but limit to whitelist
WebFormsOptions.UseLoadModulePathOnlyInAcceptedList = true;
WebFormsOptions.LoadModulePathOnlyInAcceptedList = ["ui-core", "math"]; // Safe modules only

WebFormsOptions.DisableCallMethod = false;              // Allow calling global functions
WebFormsOptions.UseCallMethodOnlyInAcceptedList = true;
WebFormsOptions.CallMethodOnlyInAcceptedList = ["showToast", "notifySuccess"]; // Whitelisted globals

WebFormsOptions.DisableCallModuleMethod = false;        // Allow calling module methods
WebFormsOptions.UseCallModuleMethodOnlyInAcceptedList = true;
WebFormsOptions.CallModuleMethodOnlyInAcceptedList = ["openDialog", "validateForm"];

WebFormsOptions.SendChecksum = true;                    // Verify server response integrity
WebFormsOptions.ChecksumName = "checksum";
Enter fullscreen mode Exit fullscreen mode

Detailed Explanation of Options and Their Security Implications

Option Description Risk if Disabled Recommendation
DisableEval When true, any command requiring eval() will be ignored. The server or a third party could send something like _ = alert('xss'), which would execute through eval() → high XSS risk. ✅ Should always be true in production.
DisableAppendJavaScriptTag Prevents adding new <script> tags via server responses. If disabled, an attacker could inject and execute malicious scripts dynamically. ✅ Must be true in production.
DisableLoadModule Blocks dynamic module loading via import(). A compromised server could load fake or malicious modules. 🔸Usually true in production unless dynamic modules are absolutely required.
UseLoadModulePathOnlyInAcceptedList When true, only modules defined in LoadModulePathOnlyInAcceptedList can be loaded. Without restriction, arbitrary modules (even external URLs) could be loaded. ✅ Should be true and tightly controlled.
LoadModulePathOnlyInAcceptedList Array of allowed module names/paths. Prevents unauthorized module execution. Include only signed or trusted modules (e.g., "math", "ui-core").
DisableCallMethod When true, no global (window) functions can be called via cb_RunMethod. Prevents unwanted execution of global functions like alert, fetch, or location.href. ✅ Recommended true in production.
UseCallMethodOnlyInAcceptedList When true, only functions listed in CallMethodOnlyInAcceptedList can be executed. Prevents unbounded access to any global function. ✅ Highly recommended true — whitelist only safe functions.
CallMethodOnlyInAcceptedList Array of allowed global functions. Defines the global whitelist for window calls. Keep this list small (e.g., "showToast", "notifySuccess").
DisableCallModuleMethod When true, no module methods can be called. Prevents remote invocation of module functions if the server is compromised. 🔸Depends on usage; best limited in production.
UseCallModuleMethodOnlyInAcceptedList When true, only module methods listed in CallModuleMethodOnlyInAcceptedList are allowed. Restricts execution to verified safe module methods. ✅ Should be enabled for strong control.
CallModuleMethodOnlyInAcceptedList Array of allowed module method names. Defines which module methods can be called. Include only essential ones, e.g. "confirm", "showDialog", "validateForm".
SendChecksum / ChecksumName When SendChecksum = true, each request includes a checksum to verify message integrity. Without checksums, attackers could forge or alter server responses. ✅ Strongly recommended for production environments.

Best Practices

  1. Enable all blocking flags in production — never allow eval() or <script> injection.
  2. Use whitelists for both modules and callable methods; they act as a built-in access control list.
  3. Use checksums or signatures to ensure responses were not tampered with in transit.
  4. Log and monitor attempts to run disallowed actions for early intrusion detection.
  5. Regularly audit and version-control your allowed module and method lists.

Summary

Security Options functions as a custom security policy for WebForms Core — effectively a programmable Content Security Policy (CSP).
Proper configuration ensures that:

  • No arbitrary JavaScript is executed,
  • Only trusted modules and functions can run,
  • Responses are verified for integrity,
  • And the client remains protected even if a server or proxy is partially compromised.

When used correctly, WebForms Core achieves the same level of runtime security as modern frameworks like Blazor Server, React, or Vue — while retaining the performance and simplicity of a lightweight web runtime.

Top comments (0)