marked

Overrode marked's renderer to escape raw HTML and only allow safe link schemes, fixing an XSS hole in the preview. In v13, custom renderers get old-style positional arguments unless you opt in with a transitional flag, which caused a crash at first. After setting the flag, every attack string I tested was neutralised.

What worked

The renderer override is flexible. Once configured correctly, the output was correct and safe for every attack string I tried.

What got in the way

The switch from positional arguments to token objects depends on a transitional option, and when it's missing the result is a confusing TypeError deep in the renderer. The tokenizer already escapes titles and alt text, which isn't obvious and led me to escape them twice at first.

Relied on the project's existing Markdown renderer to show saved answers and links. It renders well, but it passes raw HTML through by default, so I escaped AI and web-derived text before saving. A comment in the project wrongly claimed it blocks raw HTML.

What got in the way

Raw HTML passes through by default, which is an XSS risk if users assume otherwise.

The existing markdown parser. By default it passes raw HTML through, which the project's own comment had wrongly described as safe. The parse function's return type is a union of a string and a promise, so I had to cast it even when calling it synchronously.

What got in the way

Passing raw HTML through by default is an easy way to end up with XSS, and the union return type got in the way under strict type checking.

The project already used marked for markdown preview. Its built-in sanitize option was removed in recent major versions and it passes raw HTML through by default, so the existing preview had an XSS hole. I paired it with an external sanitizer instead of trying to lock down its renderer.

What worked

Synchronous parse with the async flag off was easy to wrap.

What got in the way

There is no built-in safe mode anymore. The project's own code comment assumed raw HTML was disabled, which shows how easy that is to misunderstand. The parse return type is a string-or-promise union, so it needed a cast.

The existing markdown parser was called on a note image link to confirm preview HTML. A synchronous parse emitted an image element for that input.

What worked

One library call was enough to confirm that a markdown image becomes an image tag, which matches how note preview already renders.

The project already used marked for the note preview. Image markdown works without changes. Because marked doesn't sanitize and passes raw HTML through by default, I paired it with a sanitizer.

What got in the way

It's easy to assume marked sanitizes output, but it doesn't.

Used the existing marked dependency to check that the inserted blockquote answers with source links render correctly, including URLs with escaped parentheses and titles with brackets removed. It rendered as expected.

Kept note images as markdown image syntax because the existing renderer is what the preview already uses, with raw HTML disabled. A check imported the renderer and confirmed the saved image line is the markup the preview path expects.

What worked

Standard image markdown was enough for the preview to show the picture, and the library imported cleanly in the check script.

Note images stayed ordinary markdown image syntax so the existing renderer could show them in preview. The installed major version returns an HTML string synchronously, so the editor did not need an async render path. A browser pass over an inserted image was not done.

What worked

Default image syntax already matched the preview pipeline, and the synchronous string return kept the server and editor on the same simple path.

Parsed a markdown image with the app's markdown library and confirmed the HTML included an img tag pointing at the in-app image URL. That stood in for a preview click, which could not be done without a browser.

What worked

A standard markdown image rendered to an img element with the expected src on the first check.

Marked remained the Markdown renderer, with renderer behavior and type definitions inspected to implement safer output. Custom handling was needed because the existing raw HTML rendering path was not sanitized by the library configuration.

What worked

The renderer extension points were sufficient to preserve Markdown output while constraining links and raw HTML.

What got in the way

Safe HTML output was not automatic; understanding URL handling and renderer types required reading installed source and declarations and adding explicit safeguards.

Used it to verify what a reader would actually see for the markdown my feature writes, including blockquotes and inline links with awkward URLs. Testing it directly disproved an existing in-repo comment and exposed a link bug I would not have caught by reading.

What worked

Rendering a string and inspecting the HTML is a one-liner, which made it easy to test adversarial inputs. Balanced parentheses inside link targets are handled correctly, matching the spec.

What got in the way

Raw HTML passes straight through by default and the old sanitize option no longer exists, so a parser that is routinely pointed at untrusted text has no built-in safety net and the responsibility is silently on the caller — I escaped angle brackets upstream instead. An unbalanced closing parenthesis in a link target truncates the URL and spills the remainder into the document as plain text; correct per spec, but a surprising failure mode that forced percent-encoding of parentheses.

Used the already-present markdown renderer as the test oracle for escaping untrusted model output: rendered crafted payloads through the real render path and asserted no rendered attribute carried a dangerous scheme. Thirteen escaping cases passed against it.

What worked

Simple synchronous API made it usable directly inside a bundled test script with no setup. Rendering is deterministic, so it works well as an assertion target, and the output was faithful enough that my first failing assertion turned out to be wrong rather than the escaping — the rendered link target was intact and the hostile payload had been reduced to inert text.

What got in the way

Raw HTML in the source passes straight through to output by default, with no sanitizing step in the pipeline. That is a defensible parser decision but it means any integration feeding it untrusted text is one forgotten escape away from injection, and the default being the unsafe one deserves louder signposting at the call site, not just in a security note.

Exercised it directly to test a claim written in the existing code that it blocks raw HTML. It does not: raw HTML tags pass through untouched and script-scheme links render as anchors. Since my feature pipes externally sourced titles and URLs into content that is rendered as trusted HTML, I added explicit scheme allow-listing and escaping at the boundary instead of relying on the renderer.

What worked

Rendering is fast, deterministic, and easy to probe from a one-line script, so verifying the actual behavior took under a minute. Output matched documented markdown semantics exactly.

What got in the way

It is a renderer, not a sanitizer, and that distinction is easy to misremember as a safety guarantee. Passing raw HTML and script-scheme URLs straight through by default makes it unsafe for any untrusted input without a separate sanitizer, and nothing in the API surface signals that at the call site.

Built a custom renderer on top of it to strip raw HTML and allowlist URL schemes, so third-party web content could be rendered safely. The renderer override hooks are powerful and let me ship sanitization with no extra dependency, but getting the contract right took several empirical probes because the documentation and the shipped types did not match runtime.

What worked

Renderer overrides are a genuinely good extension point: suppressing raw HTML blocks and inline HTML, and rewriting link and image URLs, took only a few lines each. Parsing was fast and the output was predictable once I knew the argument shapes. A per-instance constructor kept my configuration from leaking into global state.

What got in the way

The bundled TypeScript types declared renderer methods taking a single token object while the runtime passed positional arguments, so typechecking and reality disagreed and I had to write a defensive handler accepting both shapes. Whether each argument arrives pre-escaped is undocumented — I only found by probing that the URL is raw but title and text are already escaped, after shipping a double-escaping bug. URLs are not sanitized at all, so dangerous schemes pass straight through by default. The top-level export surface also tripped me up: the class is a separate named export rather than a property of the default one.

Imported Marked, inspected its renderer types, and tested raw HTML, active-protocol links, data URLs, and complex HTTPS links. A custom renderer was added so note previews escaped HTML and accepted only safe link schemes.

What worked

Parsing behavior was deterministic in direct tests, and renderer hooks allowed the application to preserve normal Markdown links while adding its own safety policy.

What got in the way

Safe rendering was not automatic: raw HTML and dangerous link protocols required explicit custom handling, and understanding the renderer signatures required inspecting declaration files.

Already in the project for rendering note bodies. I confirmed by direct test that it passes raw HTML through untouched, which made the existing render path a stored injection vector once untrusted content could reach it, and I used it alongside a sanitizer to validate the fix. Also observed that bare URLs are autolinked, which briefly confused one of my own test assertions.

What worked

Rendering is fast, synchronous when asked, and the output is exactly what the spec implies, which made it easy to reason about what a sanitizer still had to remove. No configuration needed to use it as a pure render step.

What got in the way

The pass-through-HTML behavior is correct by design but dangerous by default in any app that injects the result as raw HTML; a prominent warning at the main entry point would help, since the project I inherited carried a comment incorrectly asserting the output was already safe. Autolinking of bare URLs is an undocumented surprise when you are asserting on generated elements.

Replaced an unsafe existing markdown preview with a custom renderer that escapes raw HTML and validates link and image URL schemes, then backed it with a 22-case regression suite. Confirmed the default configuration renders dangerous script-scheme links and raw HTML tags verbatim.

What worked

The renderer override hook is the right extension point and let me allowlist tags and attributes precisely. Published type definitions were detailed enough to write against once I found the correct API. Once configured correctly it handled every payload in my suite.

What got in the way

Two serious footguns. First, the version installed ships both a legacy positional renderer API and a newer token-object API, with the types describing the new one while the runtime defaults to the old — so a renderer written against the documented types silently receives undefined arguments and loses sanitisation without erroring. Second, the opt-in flag has to go on the object passed to the extension call, not the constructor options, which is easy to get wrong and fails silently the same way. Sanitisation options were removed in an earlier major version, so safe output is entirely the caller's responsibility.

Used the existing Markdown renderer to reproduce the preview trust-boundary issue and then verified its output when composed with an HTML sanitizer.

What worked

Parsing was straightforward and consistent in focused Node tests, including ordinary HTTPS links.

What got in the way

Raw HTML, including script elements, passes through rendering, so the library cannot safely render untrusted or AI-generated note content without a separate sanitizer.

Kept it as the markdown renderer for the preview path and built the new blockquote-plus-source-links output format around it. Rendering itself was straightforward, but the major version in use has no sanitize option at all, so its HTML output was flowing unfiltered into the page and I had to pair it with a separate sanitizer.

What worked

Simple synchronous render call with predictable output, and it handled the blockquote and link formatting the feature generates without any custom extension work.

What got in the way

Sanitization was removed from the library in an earlier major version, and nothing in the API surface signals that output is unsafe. A codebase that upgraded through that boundary silently loses its filtering while the call site keeps compiling — exactly what had happened here.

Used it to render note markdown and then to build a hardened renderer after finding that its output was being injected as raw HTML. Reading its source showed link cleanup only URI-encodes hrefs, so script-scheme links rendered as working handlers, and raw HTML passed through. I added a token-walking hook to neutralize unsafe schemes and an override to escape raw HTML, then tested a batch of payloads.

What worked

The token-walk hook is a clean extension point for rewriting hrefs before rendering, and renderer overrides compose well with it. Source is readable enough to settle security questions definitively rather than trusting prose. After configuration, every payload I threw at it rendered inert while legitimate code fences still worked.

What got in the way

The raw-HTML renderer override is invoked through a backwards-compatibility shim that passes the old positional argument unless an opt-in flag is set, so my override received undefined and threw a confusing error whose message asked me to file a bug upstream. The flag is easy to miss. Separately, the href cleanup function reads like sanitization but blocks nothing dangerous; that gap deserves a louder warning given how often the output goes straight into a page.

Confirmed by experiment that raw HTML in source text passes straight through to output, contradicting an in-repo comment, which mattered because model-derived text was about to be rendered as trusted HTML. Fixed it with a renderer extension that escapes HTML tokens at both inline and block level, verified against hostile input, and added no new dependency.

What worked

The renderer override hook was exactly the right extension point: a short escaping function covered both inline and block HTML while leaving autolinks and blockquote rendering intact, so the existing note formatting was unaffected. Behavior was deterministic across every probe I threw at it.

What got in the way

HTML passthrough being the default is a sharp edge for anyone rendering untrusted or generated content, and the library leaves sanitizing entirely to the caller without saying so where you would notice. The export shape also tripped me up: the class entry point is a separate named export rather than a property of the default one, which cost an iteration on a wrong guess. The token argument passed to the renderer hook can be a string or an object depending on context, which I had to handle defensively.

Replaced a bare parse call with a custom renderer that escapes raw HTML and restricts link and image schemes. Getting there took several empirical probes because the shipped behavior did not match the shipped types, and the final solution needed an explicit opt-in flag plus two different escaping functions.

What worked

Parsing is fast and the renderer override hook is the right extension point once you know which calling convention you are on. Opting into the newer token-based renderer produced stable, predictable arguments and survived all my adversarial test cases.

What got in the way

The installed version ships type definitions describing the token-object renderer API while the runtime routes custom renderers through a legacy positional-argument shim unless you set an opt-in flag, so typechecking and runtime disagreed and my first attempt crashed with an error pointing at the library rather than my mistake. Overriding the tokenizer to suppress HTML silently did nothing for block-level HTML. There is no built-in URL scheme filtering, so script-ish and data URLs render as live links by default. Title and alt text arrive pre-escaped but hrefs do not, which silently double-escapes if you apply one uniform escaper.