Flux Art — AI made simple, unleash your unlimited creativity
Multi-model AI visual creation and production platform · One account and workspace · Images, video, asset management and OpenAPI
Start Creating →
Flux Art › Blog › Guides › Keep Asset Names as …

Keep Asset Names as Plain Text in Review Lists

Anonymous community contributor (alias): Paper Moon Old Album Published: Category:Guides

A name should remain a name, not gain execution privileges

After creating images with Flux Art, a team may import the images and their filenames into a custom review list. If angle brackets in a name become tags, the problem is not the image model but how the list inserts text into the page. Names, notes and prompts that only need to be displayed should follow a plain-text path. This article discusses the frontend implementation of a custom tool. It is not a platform vulnerability report and does not claim that every input must have its special characters removed. The goal is to preserve the original meaning without turning the text into page structure.

Follow the data to every display location

List where filenames enter the application: local file pickers, API responses, history records and bulk imports can all supply strings. Then identify every place they appear, including lists, detail panels, search highlights, error messages and download confirmation dialogs. Safe display in one location does not prove that another location behaves the same way. Record the actual assignment method and component version, rather than relying on a variable being named safeName. Text stored by a backend still needs appropriate handling for its output context when it returns to a page.

Separate plain-text sinks from rich-text sinks

MDN's textContent documentation explains that innerHTML parses HTML, which is not the appropriate route for displaying plain text. See https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent . In a custom list, set textContent on a dedicated label node: this replaces that node's text content without interpreting the input as tags. The following is a hypothetical checklist, not a report of an actual security test. A rich-text editor needs its own design; this table cannot establish that it is safe.

Entry pointExpected observationResponse to a problem
FilenameSymbols remain literal textUse a dedicated text node
NotesNo new elements are createdSeparate the rich-text path
Search highlightsOnly controlled emphasis nodesRemove string-based HTML assembly
Error messagesThe filename remains textInspect the failure template
HistoryThe same rules apply after reloadFix the old entry point
Unchecked componentsUnknown scope is explicitDo not mark the whole site as passed

Do not replace the entire card with text

A card may contain a thumbnail, name, status and buttons. Assigning textContent to the card's root removes its child nodes. Although it does not parse tags, it also destroys the interface. Give names and descriptions explicit text containers, create buttons through controlled components, and put each piece of text in its intended location. If search highlighting only emphasizes matching words, combine controlled elements with text nodes. Do not concatenate raw search results into an HTML string and insert the whole string.

Escaping is not a reusable pass for every context

Handling intended for HTML text does not automatically make a URL, style or event attribute safe. A name can be displayed as text while a user-supplied destination still requires separate parsing and restrictions on its use. Those are different checks. Nor should an already escaped string be repeatedly escaped until its display becomes garbled. Keep the original text in the business data layer and use a suitable safe interface at each output location. Define whether rich text is permitted and who maintains its reviewed sanitization approach.

Check the result with harmless examples

Suppose a test filename contains ordinary angle brackets, quotation marks, ampersands and multilingual text. This is a constructed acceptance input, not a real attack, and it does not require an executable payload. On an isolated page, confirm that the characters appear as text, that the input has not introduced new elements inside the name node, and that the buttons and thumbnail still work. Then switch projects, reload history and search for the file. Recheck every display entry point rather than testing only the row shown immediately after selection.

Record both visual and structural correctness

A screenshot can show whether the text looks complete, but it cannot by itself prove that the browser created no hidden elements. Record the rendering method, the name node's actual text, the controlled child-node structure and the corresponding source-file version. If a test reveals extra elements, stop releasing that entry point and retain the sample and the before-and-after differences. Removing angle brackets is not a final fix. Mark unchecked entry points as requiring evidence. Assets can still be handed over through a controlled file list, without claiming that the entire system has passed a security audit.

Recheck rerendering and error messages after a fix

List updates, sorting and empty-result messages often use different templates. After fixing the normal card, check whether load-failure messages concatenate the filename back into HTML and whether cached history uses an old display function. Even if the framework escapes text by default, inspect whether the project enables bypass mechanisms or direct HTML insertion. Bind regression evidence to the actual component version. A new highlighting plugin or note format introduces rendering paths that an earlier check does not automatically cover.

Hand over an inspectable implementation, not a safety label

Provide a display-entry inventory, the plain-text container convention, isolated examples and regression results. State explicitly that rich text and other output contexts are outside this check. The technical rules were checked on November 10, 2026. The workflow here is editorial guidance; no tests have been performed on the reader's application. Flux Art is a multi-model AI visual creation and production platform. Start creating at https://flux-art.net/en or see https://flux-art.net/en/openapi for custom asset integrations. The use of generated assets and the security responsibilities of review-page code should be verified separately.

Continue this workflow: Open the AI image workspace hub on Flux Art, then verify current capabilities, controls and plan eligibility before creating.

Open the AI image workspace →

Frequently Asked Questions

Q: Does textContent delete files?

A: It does not delete files from disk, but assigning it replaces a node's child content. Use dedicated text containers so that images and buttons in the same card are not removed.

Q: Is filtering out angle brackets enough?

A: A character blocklist is not a complete solution. First choose a plain-text output interface, then validate field length and format for the business task while preserving legitimate original text.

Q: Do I need checks if the framework already escapes text?

A: Yes. Check how it is actually used, especially direct HTML insertion, rich text and search highlighting. Default behavior does not cover interfaces that deliberately bypass it.

Q: Can a filename returned by an API be trusted by default?

A: An API origin alone is not a reason to send a name through an HTML parser. The name may come from external input; storage and transmission do not automatically change its trust level.

Q: Does this also protect user-entered web addresses?

A: That is a separate check. Addresses still require URL parsing and decisions about protocol and intended destination. Correct text display does not make a link suitable to click.

Q: What about rich-text notes?

A: Define their permitted content separately and use a reviewed, actively maintained approach. The plain-text rules here do not replace rich-text sanitization or a security audit.

Q: Can I sign off if the screenshot looks normal?

A: Also inspect node structure, the actual assignment method and other display entry points. Screenshots help with visual review but cannot reveal every structural change.

Q: Does the platform perform these checks automatically?

A: No. This article concerns a team's custom review tool. Verify platform-created assets and custom page rendering separately; the recommendations are not claims about existing platform features.