A hosted record can still reach an unsafe page
Consider an illustrative member website that stores a short customer note in a hosted backend. The note is retrieved correctly for the right user. The frontend then inserts it into the page as raw HTML because the developer wanted to preserve formatting.
The storage operation and the display operation are separate security decisions. A value can be stored successfully yet handled unsafely later. The same question applies to search results, URL parameters, imported records and generated AI responses: does the page interpret this value as ordinary data or as something the browser should execute? Review the final display location, not only the place where the value entered the system.
Choose the display rule before choosing the feature
OWASP’s XSS prevention guidance distinguishes context-appropriate output handling from HTML sanitization. For ordinary text, use a text-rendering path. If formatted HTML is genuinely required, use a maintained sanitizer and a deliberately limited content policy.
| Product field | Actual need | Design choice |
|---|---|---|
| Preferred display name | Readable text | Render as text, without HTML formatting |
| Help article excerpt | A short preview | Prefer a plain-text excerpt |
| Customer website link | A destination the user can visit | Validate allowed URL schemes and presentation |
| Formatted lesson notes | Limited formatting | Define allowed formatting and sanitize accordingly |
Do not let a minor visual preference quietly introduce a general HTML editor into an otherwise simple application.
Treat AI responses and imported text as data
A friendly-looking source is not a display guarantee. A response from an AI feature may contain markup, code samples or links. A record imported by staff may contain copied formatting. Decide how each feature should present that content before connecting it to the page.
For a customer-facing question-and-answer tool, plain text may satisfy the entire product requirement. If the interface needs formatted answers, specify the formatting it supports and inspect the whole conversion path. A library that transforms text into HTML introduces another component to maintain. Do not rely on an instruction to the AI model as the browser’s security boundary; the application must handle the returned content appropriately.
Use CSP as a reviewed additional layer
A Content Security Policy, or CSP, restricts certain kinds of content the browser may load or execute. MDN’s CSP implementation guide explains the role of hashes and nonces in allowing intended scripts. A policy must match the actual application and its delivery method.
Ask the developer to explain every script source the page permits. Include analytics, payment integrations and login dependencies in the review. Validate a proposed policy in a test environment, then confirm real user journeys still work. Avoid copying a policy from an unrelated website or broadly relaxing it whenever something breaks. CSP adds a layer of defense; it does not make an unsafe rendering path a good design.
Give reviewers concrete acceptance criteria
- Inventory display paths: identify where user text, query parameters, imported content and AI output appear.
- State the intended format: plain text, a validated link or a restricted rich-text format.
- Review exceptional code: inspect places that bypass the framework’s normal escaping or directly build HTML.
- Check transformations: follow content through formatting and sanitizing steps to its final display.
- Keep controls current: assign an owner to rendering libraries, sanitizers and the deployed CSP.
Use a controlled test environment and benign fixtures agreed with the developer. The acceptance question is whether text stays text and only the intended formatting is allowed, not whether the page merely survives one copied test string.
What Gammal Tech changes and what the website controls
Gammal Tech’s documentation describes hosted login and per-user, per-project JSON storage. This can reduce the local backend your company maintains. The frontend remains responsible for displaying the information it receives.
As an application-design inference, malicious code running on a valid website can interact with information and functions available to that page. Registering the domain does not distinguish your intended script from a malicious change deployed on the same domain. Therefore review publishing access and display code together. Moving data off the web server is useful, but it does not turn all pages that consume that data into trusted pages.
Keep the review attached to the feature
Record the display rule beside the product requirement. For example: “Customer notes support plain text only; line breaks are preserved without interpreting HTML.” A future designer can then improve the layout without accidentally changing the trust boundary.
Repeat the review when the feature adds rich text, new link types, a different AI renderer or an external widget. If suspicious page behavior is reported, preserve the relevant release and diagnostic evidence, restrict unsafe publishing access and have the affected path assessed. Fix the entry or display problem before assuming a clean database alone has resolved the incident.
Common questions
Can XSS affect a website with no local database?
Yes. XSS concerns how the page processes untrusted content. Data may come from a URL, hosted service, imported record or another browser-accessible source.
Is a CSP enough to prevent XSS?
Use CSP as an additional layer. The website still needs suitable output handling, safe design for rich content and maintenance of the code that renders it.