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:
- Real comment nodes starting with
[web-forms] - 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)
| Layer | Responsibility |
|---|---|
| Application | HTML‑encode user input |
| Browser | Enforce HTML parsing rules |
| WebForms Core | Transport structured instructions |
| WebFormsJS | Enforce runtime execution policy |
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 existsHTML 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.
Top comments (2)
This is a very insightful deep dive into security!
As a beginner currently focusing on Front-end (HTML/CSS/JS), I'm starting to realize that security is a full-stack responsibility.
For someone just starting out, what is the #1 security 'golden rule' we should keep in mind when building our first interactive forms?
Great share!If we consider the situation that you are building a client-server system:
I remember several years ago there was a system that did not allow changing the username after registration, only by adding the disabled attribute to the text input!