hono npm package: is it safe?

The applyProps function directly assigns untrusted __html content to container.innerHTML when the 'dangerouslySetInnerHTML' prop is used. This is standard React-like behavior but constitutes an XSS sink if untrusted data flows into __html.

The middleware accepts an arbitrary method string from user-controlled input (form field, header, or query parameter) and passes it directly as the method of a new Request. There is no allowlist validation, so an attacker can set the method to any value (e.g., CONNECT, TRACE, or custom verbs), potentially bypassing upstream security controls that only inspect c.req.method before this middleware runs.

When overriding via header, the original body (c.req.raw.body) is forwarded to the internally dispatched request while the method changes (e.g., GET to POST/DELETE). This breaks the typical assumption that GET has no body and may cause downstream handlers or proxies to misinterpret or smuggle requests.

The query-string override path copies the original request body and headers unchanged into a request with an attacker-specified method. Because the method can be arbitrary and no validation is performed, this can be abused to reach handlers that should not be reachable for the original method, and the override is not removed by intermediaries that do their own parsing.

The verifyWithJwks function performs an unvalidated fetch to options.jwks_uri. If this URI originates from untrusted input, it could enable SSRF or trigger unexpected network requests. However, the URI is typically configured by the developer, not derived from the token itself.

In verifyWithJwks, the algorithm is taken from the JWKS key (matchingKey.alg) falling back to the token header's alg. If the JWKS key does not specify alg, an attacker-controlled token header could dictate the algorithm used for verification, potentially enabling algorithm-confusion attacks. The verify function itself accepts an alg parameter that is trusted from the caller, but verifyWithJwks derives it partly from token data.

The code builds an inline <script> tag string: <script${nonce ? nonce="${nonce}" : ""}>document.querySelector('#${id}').textContent+=${JSON.stringify(stylesStr)}</script>. While this pattern is part of the intended SSR CSS helper behavior (injecting styles at runtime), it dynamically constructs JavaScript that is executed in the browser. If the id or nonce values are attacker-controlled, this could lead to DOM-based XSS or script injection. In practice, id is defined by the library author (DEFAULT_STYLE_ID) and nonce comes from the developer, so exploitability is limited, but the pattern of generating inline scripts is a notable security-relevant behavior.

The code generates inline <script> tags containing JavaScript that manipulates the DOM. While this is intended for streaming SSR error boundaries, it introduces XSS-like behavior by embedding dynamically generated script content. If the scriptNonce is not properly enforced or if user-controlled data reaches the template IDs or content, it could lead to arbitrary script execution.

Although no explicit eval/new Function is present, the code constructs and injects JavaScript strings that are executed in the browser. This dynamic script generation can be abused if inputs are not sanitized, potentially leading to code injection.

The ErrorBoundary component injects fallback HTML and children content directly into templates and script blocks without explicit sanitization in this file. If the content originates from untrusted sources, it could lead to cross-site scripting (XSS).

applyProps iterates over all keys in attributes and assigns to DOM properties (e.g., container.value, container[key]) or attributes. While this is typical for a renderer, if attributes originate from untrusted sources, it could allow property clobbering or prototype pollution (e.g., setting '__proto__' or 'constructor' through attributes). No explicit sanitization of keys is performed before using them in bracket notation or setAttribute.

The 'dangerouslySetInnerHTML' prop is honored by directly assigning to container.innerHTML, which can lead to XSS if used with untrusted data. This is a known React-like API but remains a potential security risk if developers pass unsanitized content.

Attributes are set via setAttribute after being stringified. If attribute names or values come from untrusted input, this could set event handlers or dangerous attributes (e.g., 'srcdoc', 'href:javascript:...'). No allowlist is present.

The default origin is set to '*', which allows any origin to access the resource. If credentials are enabled (opts.credentials), this can lead to unauthorized access. However, this is a common default and not inherently malicious.

The module exports md5 and sha1 helpers that use MD5 and SHA-1, which are cryptographically broken for collision resistance and unsuitable for security-sensitive hashing. While not inherently malicious, exposing them as general-purpose crypto utilities can lead to insecure usage in downstream applications.

verifyWithJwks performs a fetch to options.jwks_uri without validating the URI scheme/host against an allowlist. A caller passing attacker-controlled jwks_uri could cause the process to make arbitrary outbound requests (SSRF). This is a design-level risk rather than injected malicious code.