> For the complete documentation index, see [llms.txt](https://community-test.logicnets.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://community-test.logicnets.com/release-9/platform-documentation/system-administration/security/security-vulnerabilities-and-content-modeling.md).

# Security Vulnerabilities and Content Modeling

## Introduction

Part of LogicNets' security architecture is implemented at the modeling level and impacts how you can build content safely. This topic discusses security steps, but you can reach out to your Account Manager for more information about the security architecture in place for the LogicNets platform.

## UI Security

LogicNets set the security level to ‘safe’ as part of security improvements implemented to guard against cross-site scripting (XSS). This means that the system performs HTML escaping for all interpolated text--text that is rendered from $(..) in the output of all UI parts.

LogicNets implemented this safeguard to help content modelers build safer applications and to create awareness that $(..) can potentially allow malicious user inputs that contain XSS vulnerabilities, such as script statements. For example, a data object containing

```
<b>My Caption</b>
```

will be printed as My Caption on screen, instead of **My Caption**.

The above example is quite harmless. However, if you had a scenario where your application displayed the user name on screen as ‘Hello $(user\_name)’, bad actors would be able to enter as their user name scripts that could allow for XSS:

```
<script>alert(“Hey I can run malicious code from this site”)</script>
```

HTML escaping prevents this from happening, as the system renders the caption as text only.

For additional information about and examples of XSS, go to <https://owasp.org/www-community/attacks/xss/>.

## HTML-Escaped Parts

Below is the list of LogicNets form parts that are more secure because of HTML escaping:

* Text Input
* DbGrid
* Text Area
* Check Box
* RadioList
* DropDown
* CheckList
* Numeric Input
* Date Input
* Title
* Warning
* Error
* Button
* DbGrid
* Upload
* Download
* HTML

There may still be times when you want to use the $(..) construction for dynamic resolution of formatted labels or captions, for example. If you are confident your content will be safe during your application's runtime, you can use the html(..) function inside the $(..) to prevent escaping the content.

For example, you have a data object called *user\_message* and it contains the following:

```
<b class="error">An error has occurred</b>
```

use *$(html(user\_message))* to ensure that the HTML is not escaped in the comment node.

#### Set Data Object

In addition to the above form parts, the set data object process part has an option to set the value as html, marking the content as a safe HTML string.

## Non-HTML-Escaped Parts

There are some LogicNets parts that are used to render static content and safe HTML, and these are not HTML escaped. These parts are:

* Title
* Warning
* Error
* HTML parts/nodes that include the text HTML, comment, and format-variable parts

LogicNets has added a part parameter called *Escape $(…) text* to these parts to enable automatic escaping of the $(..) text in the captions, if desired and determined to be safe. This parameter is enabled by default for newly added nodes.

## Locating Security Weaknesses in Existing Modeled Content

To facilitate the migration of applications to the new security standard you can run the validation tool on each of your projects. This allows the system to provide you an overview of those parts with $(..) in the output that are affected by this change. The system displays a warning in the node and part editors and in the project-validation tool when text, comment, and format-variable parts are used with $(…) in captions and the “escape-$()-text” flag is not set.

## Resolving Security Weaknesses

You can resolve warnings by enabling the *escape-$(..) text* flag.

When you use *$(html(safe\_text))* to explicitly indicate that content is safely formatted HTML, the system does not show a warning message.

The validation tool also offers the option to automatically resolve the vulnerabilities. If you choose this, the validation tool will do the following:

* Enable the *escape-$()-text* flag in the comment and format-variable part declarations in the models.
* Convert the text HTML part to a comment part.

## Security Vulnerabilities of Client-Script Part

With the client-script part (write\_script) there are similar security vulnerabilities that could allow a bad actor to execute JavaScript in the browser modeled in a logicnet. Consequently, you should use this part with care. We strongly recommend the following when using this part:

* Properly encode all data inserted into the script using $(..).
* Call the JavaScript encode method for strings: myfunction("$(encode\_js(…))").
* Do not JavaScript-encode a JSON encoded string when using it directly in a data object:

  ```
  var json=$(json_str)
  ```
* If you use JSON.parse you must JavaScript-encode your data:

````
```
````

````
JSON.parse("$(encode_js(json_str))")
```
````


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://community-test.logicnets.com/release-9/platform-documentation/system-administration/security/security-vulnerabilities-and-content-modeling.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.