Secure input against XSS

We must stop reflected XSS on the comment widget before the production push. Sanitize user-submitted comment text so any angle brackets, script tags, and event-attribute syntax are escaped when rendered, and apply a strong Content-Security-Policy that disallows inline scripts. Verify by posting a comment containing <script>alert('xss')</script> and confirming it renders as text.

Before I send this XSS fix to security review, make approval obvious: show the original input and the escaped output side by side, summarize which characters we escape and which we allow (e.g., basic Markdown), highlight where we apply server-side escaping vs client-only, and call out any remaining places that still render raw HTML like admin previews.

An admin reported that a stored comment containing an iframe rendered as active HTML on the admin preview page, but on the public site the same comment is escaped. I’m worried we missed server-side escaping on the admin route or that a legacy render path bypasses the sanitizer. I don’t know whether the unsafe output comes from stored HTML or a separate rendering pipeline. What tests and quick checks would confirm whether this is a rendering-path bug or bad storage, and what immediate change should I make to stop admin users seeing executable markup?

Over multiple incidents we find XSS only in rare admin views and old templates: public pages are fine but legacy renderers bypass the sanitizer. We spend emergency cycles patching them as they appear. Which two consistent practices will prevent these regressions going forward — what to add to the template system or CI and what developer habit to enforce on review?