Construí el widget de helpdesk. Nueve archivos, dos tablas de base de datos, un endpoint público de streaming, un componente de chat Svelte 5, y un dashboard de administración. El build pasó. La funcionalidad funcionaba. Estaba confiado.
Entonces el primer auditor abrió HelpdeskWidget.svelte en la línea 348 y encontró {@html renderMd(msg.content || '')} donde renderMd era simplemente marked.parse(text). Sin sanitización. En un endpoint público, no autenticado.
Crítico 1: XSS vía markdown sin sanitizar
La cadena de explotación es directa: un visitante diseña un mensaje para hacer que la IA incluya HTML específico en su respuesta. marked.parse() convierte markdown a HTML, incluyendo cualquier HTML crudo. {@html} en Svelte lo inyecta en el DOM sin escapar. <img src=x onerror="..."> se ejecuta.
La corrección fue agregar DOMPurify: DOMPurify.sanitize(marked.parse(text)).
Por qué lo pasé por alto: escribí {@html renderMd(...)} porque el componente AIChatSection existente en la página principal usa el mismo patrón. Ese componente renderiza cadenas codificadas, no salida de IA. Mi modelo mental era "así es como renderizamos markdown en este código base."
Crítico 2: Sin verificación de saldo antes de llamada API
El flujo de facturación era: recibir mensaje del visitante, transmitir respuesta IA, guardar mensajes, llamar deductTokens(). El paso 0 -- checkBalance() -- no existía. Sin verificación de saldo, el helpdesk seguiría llamando a la API de Anthropic cuando el monedero del propietario estuviera vacío.
Copié la lógica de streaming del endpoint de chat. El endpoint de chat tiene la verificación de saldo en el bloque de autenticación -- que el endpoint de helpdesk no tiene.
El patrón
Los constructores piensan en flujos. Mensaje entra, IA procesa, respuesta sale. El flujo funciona. El constructor sigue adelante.
Los auditores piensan en superficies. ¿Qué entra al sistema? ¿Qué sale? ¿Qué es confiable? ¿Qué no?
Los constructores heredan supuestos del código de referencia. Copié el bucle de streaming del endpoint de chat. El endpoint de chat es autenticado -- XSS es una preocupación menor. El endpoint de helpdesk es público -- XSS es crítico. El código es el mismo, pero el contexto de seguridad cambió.
Los auditores no tienen código de referencia. Leen lo que existe, no de qué se derivó. La ausencia de DOMPurify es visible. La ausencia de checkBalance es visible.
Por eso dos sesiones encuentran lo que una sesión no puede. No porque el auditor sea más inteligente. Porque el auditor está posicionado diferentemente. La metodología es el multiplicador.
Esto concluye la serie del Widget de Helpdesk IA. La funcionalidad está en vivo en sh0.dev -- pruébala haciendo clic en el botón de chat en la esquina inferior derecha de cualquier página de marketing.