Security in WebForms Core

What is WebForms Core?

Elanat's WebForms Core technology is a modern web development framework based on a completely stateless server architecture, where all application state is stored on the user's browser, so the server does not retain any information from previous sessions. This approach makes the server lightweight, scalable, and fast, and can easily respond to a large number of requests. WebForms Core includes a server class, WebForms, and a lightweight client-side library, WebFormsJS, that communicate bidirectionally, allowing developers to dynamically and interactively update HTML elements without writing complex front-end code. The framework uses lightweight data (such as INI instead of JSON) to improve performance and provides features such as dynamic updates without full page reloads, lazy loading, support for multiple programming languages, and WebSocket communications for real-time interactions. WebForms Core's main focus is on simplifying web development with full server-side UI control, reducing the need for front-end development, preserving the server-side development experience, and improving performance and scalability, while minimizing bandwidth consumption and making it easy to create responsive and interactive user interfaces.

HTML‑Aware Parsing, Standard Web Encoding, and Client‑Side Controls

WebForms Core is a server‑driven web framework where client‑side actions are executed based on structured server instructions.
These instructions can be delivered with HTML or without HTML, depending on the request type.

Understanding this distinction is essential for correctly reasoning about security.

Two Delivery Modes for WebForms Instructions

1. Responses Without HTML (Pure Instruction Payload)

When the server response does not contain HTML (for example: secondary requests, SSE, or AJAX‑style responses), WebForms instructions are sent directly:

[web-forms]
_=steal()

Key Characteristics

• No HTML parsing is involved
• No DOM is created
• Instructions are consumed only by WebFormsJS
• Browser HTML security rules do not apply here because HTML does not exist

In this mode, security relies entirely on:

• Trusted server responses
• WebFormsJS Security Options (described later)

2. Responses With HTML (Initial Page Load)

When HTML is present, WebForms instructions must be embedded inside the HTML document.
WebForms Core supports two equivalent containers, both interpreted by WebFormsJS.

WebForms Instructions Embedded in HTML

A) HTML Comment Container (Recommended – WebForms Core 2)

<!--[web-forms]
_=steal()-->

• Used only when HTML exists
• Keeps the document fully valid and standard
• Does not add nodes to the DOM
• Parsed by WebFormsJS by scanning comment nodes
• [web-forms] must appear at the start after trimming

B) <web-forms> Tag Container (Legacy / Backward Compatibility)

<web-forms ac="_=steal()"></web-forms>

• Used only when HTML exists
• Parsed by WebFormsJS via DOM traversal
• Still supported for compatibility
• Less clean because it introduces a custom DOM element

Critical Security Principle: HTML Encoding

WebForms Core does not sanitize user input.
It follows the exact same security rule as standard web development:

If user input is HTML‑encoded, it cannot be executed.

Encoded Example (Safe)

<!--[web-forms]
_=steal()-->

<web-forms ac="_=steal()"></web-forms>

Result

• No real HTML comment is created
• No <web-forms> element exists
• WebFormsJS sees nothing
• Nothing is executed

This behavior is identical to:

<script>alert('xss')</script>

Why Encoding Works Reliably

WebFormsJS only parses:

1. Real comment nodes starting with [web-forms]
2. Real <web-forms> elements

Encoded content produces:

• Plain text
• No DOM nodes
• No executable instructions

Client‑Side Security Options in WebFormsJS

For non‑HTML responses and runtime execution control, WebFormsJS provides a configurable security policy.

Recommended Production Configuration

WebFormsOptions.DisableEval = true;
WebFormsOptions.DisableAppendJavaScriptTag = true;

WebFormsOptions.UseLoadModulePathOnlyInAcceptedList = true;
WebFormsOptions.LoadModulePathOnlyInAcceptedList = ["ui-core", "math"];

WebFormsOptions.UseCallMethodOnlyInAcceptedList = true;
WebFormsOptions.CallMethodOnlyInAcceptedList = ["showToast", "notifySuccess"];

WebFormsOptions.UseCallModuleMethodOnlyInAcceptedList = true;
WebFormsOptions.CallModuleMethodOnlyInAcceptedList = ["openDialog", "validateForm"];

WebFormsOptions.SendChecksum = true;

What This Achieves

• Blocks eval() execution
• Prevents dynamic <script> injection
• Restricts module loading to trusted paths
• Restricts callable functions to whitelisted ones
• Verifies response integrity

This functions as a programmable runtime CSP.

Security Responsibilities (Clear Separation)

No layer overlaps responsibility.

Final Summary

• WebForms instructions exist in two modes:

  • Pure instruction payloads (no HTML)
  • HTML‑embedded containers (comment or tag)

• The comment and <web-forms> containers exist only when HTML exists

• HTML encoding alone is sufficient to neutralize injection attempts

• WebFormsJS adds a second security layer through configurable execution controls

• Security behavior is identical to standard web applications

Final Rule

If your HTML is safe, your WebForms Core usage is safe.

This is by design — not by coincidence.