feat(security): sanitize and cap user-pasted contract source before rendering in CodeViewer

[luhrhenz]

The problem

User-pasted contract source (up to 500,000 characters per lib/codeStore.ts) eventually gets rendered by components/CodeViewer.tsx. Depending on how that component renders (syntax highlighting libraries sometimes have their own HTML-generation paths), there's a real question of whether extremely large or specially-crafted source input could cause rendering performance problems or, in the worst case, any kind of injection issue — this needs to be verified, not assumed safe.

Why this is hard

Verifying this properly means understanding exactly how the syntax highlighter renders content (does it produce React elements safely, or does it ever touch dangerouslySetInnerHTML?) and stress-testing with pathological input (extremely long single lines, deeply nested comment-like structures, unusual Unicode) rather than just normal Rust source.

Direction

• Audit CodeViewer.tsx and whatever syntax-highlighting mechanism it uses for any dangerouslySetInnerHTML or equivalent raw-HTML-insertion path
• Stress-test rendering with pathological input (very long lines, unusual Unicode, adversarially crafted comment-like content) and fix any performance or rendering issues found
• Add a rendering-side length/line-count guard independent of the storage-side cap in codeStore.ts, since a future change to that cap shouldn't silently remove this protection

Acceptance criteria

• No raw-HTML-insertion path exists for user-controlled contract source, or its safety is explicitly verified and documented
• Pathological input does not cause a rendering hang or crash

Relevant files: components/CodeViewer.tsx, lib/codeStore.ts

---

This is part of a deliberately hard "challenge" batch — the goal is a real rebuild/fix, not a cosmetic patch. Open a draft PR early and describe your approach before going deep.

[Babigdk]

Hi Maintainer! I'd like to work on this issue if it's still available.

I have experience securing React/TypeScript applications, auditing rendering pipelines, and hardening components that process user-controlled input. This issue aligns well with my experience in frontend security, performance optimization, and defensive rendering.

My approach will be to first audit the complete rendering flow—from lib/codeStore.ts through components/CodeViewer.tsx and the underlying syntax-highlighting library—to verify whether any user-controlled content can reach a raw HTML rendering path (such as dangerouslySetInnerHTML or equivalent). Rather than assuming the current implementation is safe, I'll validate the renderer's behavior and document the findings.

I'll then stress-test the viewer with adversarial inputs, including extremely long single-line files, oversized sources, unusual Unicode sequences, and crafted comment-like structures to identify rendering bottlenecks or potential injection vectors. Based on the results, I'll implement an independent rendering-side guard using configurable length and line-count limits, ensuring the UI remains responsive even if the storage-side limit changes in the future.

I'll accompany the implementation with focused tests covering pathological inputs, verify that rendering remains stable without hangs or crashes, document any security guarantees around the rendering path, and open a draft PR early to share my approach before proceeding with the full implementation. Before requesting review, I'll ensure linting, builds, and all tests pass successfully.