Clarification Request: Standardized Guidance for Detecting Malicious Patterns in Widget HTML
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- html
- Domain
- documentation, security
Research direction
Start with specification/2026-01-26/apps.mdx around the Host behaviour guidance linked in the issue. Review the existing wording and document a consistent baseline for malicious-pattern detection, including the expected host response; done means the security expectation is explicit while preserving legitimate widget compatibility.
Written by the indexing model from the issue text.
Description
The current guidance mentions Host behaviour should:
Could we clarify whether there is a standardized guideline or recommended policy for what should be considered a “malicious pattern” in the context of hosted/embedded widgets?
Specifically:
-
Is there an existing standard list or definition of patterns that hosts are expected to scan for?
-
Are there recommended categories of suspicious content (for example, script injection, inline event handlers, javascript: URLs, unexpected iframe usage, etc.)?
-
Is the expectation that hosts implement:
- strict blocking,
- best-effort heuristic scanning,
- or logging/telemetry only?
Context
For third-party widgets/apps, full HTML sanitization is often not practical because it can break legitimate functionality. It would be helpful to understand whether there is a common baseline guideline that hosts should follow for detecting clearly malicious content without overly restricting valid widget behavior.
Goal
Align host implementations on a consistent security expectation while preserving compatibility for legitimate third-party widgets.
- Dominant language
- TypeScript
- Stars
- 2.9k
- Forks
- 387
- Avg merge
- 3h 21m
- Merged PRs (30d)
- 6
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelcontextprotocol/ext-apps
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
modelcontextprotocol/ext-apps#767 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
modelcontextprotocol/ext-apps#742 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
modelcontextprotocol/ext-apps#711 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
modelcontextprotocol/ext-apps#706 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
modelcontextprotocol/ext-apps#703 · 1 reaction ·
All issues in modelcontextprotocol/ext-apps
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
fullcalendar/fullcalendar#8106 ·