Markdown facilita a escrita de artigos, mas o navegador não exibe Markdown diretamente como conteúdo formatado. Em algum ponto, o sistema transforma a fonte em HTML. Essa transformação precisa ter um contrato claro: quais extensões são aceitas, que HTML pode sair, onde a limpeza ocorre e como a publicação mantém uma cópia da fonte original. Sem essas respostas, cada camada começa a corrigir o conteúdo de um jeito diferente.

Preserve a fonte e gere uma saída reproduzível

Guarde o Markdown recebido em um campo ou coleção própria e associe-o ao identificador do post. Gere o HTML a partir dessa fonte usando uma versão conhecida do compilador. Se a saída publicada precisar de ajuste, corrija a regra ou o conteúdo e gere novamente. Editar apenas o HTML final cria divergência: na próxima publicação, a conversão pode remover a correção ou duplicar elementos.

Inclua no contrato a versão do formato, os plugins habilitados e as regras para links, imagens e blocos de código. O formato de entrada não deve depender de extensões invisíveis ao editor. Se uma extensão é permitida, ela precisa aparecer no preview e ser renderizada da mesma forma no servidor.

Trate o HTML como entrada não confiável

Autores podem colar conteúdo vindo de editores, páginas ou documentos. Algumas ferramentas preservam atributos e elementos que não estavam visíveis na edição. Se a aplicação renderiza a saída com HTML direto, uma string maliciosa pode executar código no contexto do site. Converta a fonte com uma biblioteca mantida e aplique uma política de sanitização adequada à finalidade do artigo antes de renderizar.

Uma allowlist costuma ser mais fácil de revisar do que tentar remover uma lista crescente de elementos perigosos. O artigo pode precisar de parágrafos, títulos, listas, links e código, mas não precisa automaticamente de scripts, iframes, handlers de evento ou URLs javascript:. Avalie target, rel, protocolos e atributos aceitos. Não permita um recurso só porque o editor consegue produzi-lo.

Sanitização não substitui escape em outros contextos. Uma saída segura para o corpo HTML pode ser insegura se for interpolada em JSON-LD, atributo HTML, URL ou JavaScript. Cada contexto de saída precisa da codificação apropriada. Ao serializar JSON-LD, use um serializador JSON e neutralize caracteres que poderiam fechar a tag script.

Valide antes de gravar

O servidor deve validar título, slug, resumo, tags e tamanho do Markdown. Uma validação no formulário melhora a experiência, mas qualquer cliente pode ignorar o formulário e enviar uma requisição própria. A rota de escrita precisa repetir as verificações. Normalize o slug uma única vez e verifique duplicidade na fonte persistente, considerando concorrência entre duas criações com o mesmo valor.

O preview ajuda a encontrar problemas de formatação, mas deve usar as mesmas regras da publicação. Se o preview usa outra versão ou habilita uma extensão a mais, o autor pode aprovar algo que o leitor não verá. Armazene as alterações no formato original e gere o HTML no servidor ao salvar.

Migrações e conteúdo legado

Um CMS que já guarda HTML pode precisar recuperar Markdown para permitir novas edições. Essa conversão inversa é aproximada: alguns atributos, detalhes de tabela ou componentes não têm representação equivalente. Preserve a saída legada enquanto a fonte recuperada não tiver sido revisada. Marque quais artigos possuem fonte autoral e quais usam um rascunho reconstruído.

Antes de alterar o compilador, selecione artigos com listas, imagens, tabelas, links externos e código. Compare o HTML gerado antes e depois, incluindo os atributos que não devem aparecer. Teste strings com tags inesperadas e URLs malformadas. A migração fica mais previsível quando cada etapa deixa a fonte original disponível para recuperação.

OWASP: Cross Site Scripting Prevention Cheat Sheet · Marked: segurança