Managing HTML Permissions and XSS Risk in Khoros Community

Overview

Khoros Community supports HTML in posts and signatures so your users can format content, embed images, and enrich discussions. However, allowing HTML also introduces potential risk from cross‑site scripting (XSS) if it is not carefully controlled.[1]

This article explains:

• How HTML permissions work in Khoros Community.
• When XSS reports indicate a real vulnerability versus expected behavior for trusted users.
• Best practices for configuring your community to balance usability and security.[1][2]

Khoros Community controls which HTML tags a user can use in the text editor through permissions on their role.[2]

The key permissions are:

• Default permissions
  Basic formatting only (e.g., <b>, <i>, <p>, lists, tables). These tags are always allowed for all users.[2]
• Use simple HTML in posts and signatures
  Adds limited tags such as <img> with safe attributes for simple content like inline images.[2]
• Allow user to use advanced HTML in posts and signatures
  Adds more structural tags (e.g., headers like <h1>–<h6>) but still with a controlled set of attributes.[2]
• Use full HTML in posts and signatures
  Almost no restrictions on HTML tags and attributes, with only a few exceptions such as blocking <script> and some meta tags.[2]
  This permission is meant for highly trusted users, because it effectively allows them to post “almost anything” in HTML.[1]

In addition, the Embed content hosted by third parties permission controls whether a user can embed third‑party resources via attributes such as img src=, iframe src=, etc.[2]

Cross‑site scripting (XSS) occurs when untrusted user input is stored or reflected and then rendered as executable JavaScript in another user’s browser. This allows actions like:

• Running arbitrary JavaScript in the victim’s session.
• Stealing cookies or tokens if they are not protected.
• Posting or modifying content as the victim.[1]

Khoros Community runs a server‑side sanitation algorithm against HTML that users post, which blocks the vast majority of dangerous patterns.[1] However:

• Attackers continually look for new ways to encode scripts and bypass filters.
• It is impossible to guarantee that every possible XSS vector can be blocked purely by automated sanitization.[1]

Because of this, the most important defense is how you assign HTML permissions to users.

From a Khoros product/security perspective, there is a crucial distinction:

Case 1 – XSS from a user without Advanced or Full HTML

If all of the following are true:

• The attacking user does not have:
  • “Use full HTML in posts and signatures”, and
  • “Allow user to use advanced HTML in posts and signatures”,[1]
• The board where the payload was posted does not allow Full HTML posting for regular users,
• Community defaults do not allow Full HTML for that user,
• Yet the user can still inject JavaScript that executes in other users’ browsers,

then this is treated as a security vulnerability and should be reported to Khoros Support for investigation by our security team.

Case 2 – XSS from a user with Full HTML

If the user does have “Use full HTML in posts and signatures” and can inject and run JavaScript, this is considered expected behavior for that permission level, not a product vulnerability.[2]

The reason:

• Full HTML is explicitly designed to allow trusted users to post almost arbitrary HTML content, with only limited blocking of certain tags. It is intended for admins or highly trusted content authors, not general users.[1][2]
• With Full HTML, users can already embed powerful constructs such as complex layouts, embedded iframes, and external resources, which inherently carry security responsibilities.[2]

In this case, the correct mitigation is not a product change, but to:

• Remove Full HTML from non‑trusted roles.
• Limit that permission to a very small, trusted group.

Khoros strongly recommends the following configuration to reduce XSS risk while maintaining flexibility:[1]

1. Deny HTML permissions by default
   • Set default permissions for:
     • “Use full HTML in posts and signatures”
     • “Use simple HTML in posts and signatures”
       to DENY for all general users.[1]
2. Grant HTML only to trusted roles
   • Create dedicated roles for trusted users (e.g., moderators, community managers).
   • Grant Simple or Advanced HTML only to those roles and assign them selectively.
   • Grant Full HTML only to a very small number of trusted admins or content specialists.[1]
3. Use built‑in features instead of raw HTML for most users
   • Enable image upload so users do not need raw HTML for screenshots.[1]
   • Use built‑in video and embed features (such as rich content previews) instead of custom <iframe> or script‑based embeds.[1]
4. Restrict embedding of third‑party content where appropriate
   • Review the “Embed content hosted by third parties” permission and consider limiting it to trusted roles if your security policy requires strict control over external resources.[2]
5. Periodically audit roles and permissions
   • Regularly check which roles have Simple, Advanced, or Full HTML permissions.
   • Remove these permissions from any broad or legacy roles where they are no longer needed.[1]

When creating messages via the Khoros Community REST API (for example, POST /api/2.0/messages), the platform applies the same HTML permission model that it uses for posts created in the UI:[2]

• If the API call is authenticated as a user with Default or Simple HTML, their body content is sanitized according to those permissions.
• If the API call is authenticated as a user with Full HTML, the body is accepted with minimal restrictions, consistent with that permission’s intent.[2][1]

This means:

• If a security test shows that a user with Full HTML can submit an XSS payload via the API, that is expected configuration behavior, not a product vulnerability.
• To prevent such behavior, you must:
  • Avoid granting Full HTML to untrusted users.
  • Ensure any automation using API session keys or tokens with Full HTML accounts is strictly controlled.

When you receive an XSS report against your community, we recommend checking the following before raising a security case:

1. What permissions does the attacking user have?
   • Does the user have “Use full HTML in posts and signatures” or “Allow user to use advanced HTML in posts and signatures”?[1]
2. Where was the payload posted and executed?
   • Identify the specific board, component, or API endpoint involved.
3. Is the board or community default configured to allow Full HTML for regular users?
   • If yes, this is a configuration/permissions issue, not a product bug.
4. Can a user without Advanced/Full HTML reproduce the XSS?
   • If a true low‑privilege user (with only default or simple HTML) can trigger XSS, this should be reported to Khoros Support as a potential vulnerability.

By following this checklist and the best practices above, you can greatly reduce XSS risk in your community and avoid false positives where behavior is simply the result of intentionally granting Full HTML to trusted users.[1]

References

1. HTML permissions and user experience
2. Allowed HTML Tags in the Community text editor