Make is great at moving data between systems. That convenience is exactly why XSS can sneak in so easily.

I’ve seen teams assume XSS is only a frontend bug. Then they wire Make into forms, CRMs, CMS tools, Slack, email builders, internal dashboards, and webhook handlers. Suddenly untrusted input is flowing through ten services, getting reformatted three times, and landing in HTML somewhere nobody reviewed carefully.

That’s the real problem with XSS in Make automations: Make usually isn’t the final vulnerable layer, but it can absolutely become the delivery mechanism.

Where XSS shows up in Make workflows

Make scenarios often process data from sources like:

  • public forms
  • webhook payloads
  • CRM fields
  • email subject lines
  • markdown content
  • support tickets
  • CMS entries
  • spreadsheet cells
  • AI-generated text

Any of that data can contain HTML or JavaScript payloads. If your automation later inserts it into a webpage, admin panel, email template, or embedded widget without proper output encoding, you’ve built an XSS pipeline.

A common flow looks like this:

  1. User submits a form
  2. Make receives the webhook
  3. Make transforms fields and stores them somewhere
  4. Another step publishes the content into a site or internal tool
  5. The app renders it as HTML

That final rendering step is where the script executes, but the unsafe trust decision probably happened earlier.

The core tradeoff: automation speed vs trust boundaries

Make is optimized for speed. Drag modules together, map fields, ship it. That’s the upside.

The downside is that trust boundaries get blurry fast.

Pros of using Make with user-controlled content

  • Fast integration between tools
  • Easy field mapping and transformation
  • Good visibility into data flow
  • Useful for moderation, enrichment, and routing
  • Can centralize validation before data reaches downstream systems

Cons of using Make with user-controlled content

  • Encourages “just pass the field through” behavior
  • HTML content often gets treated as plain text by accident
  • Teams assume upstream tools already sanitized input
  • Encoded and decoded variants can get mixed across modules
  • Security ownership becomes unclear across app, CMS, and automation teams

That last one is the killer. I’ve watched teams argue over whether the form provider, Make, or the frontend should sanitize. My answer is always the same: validate early, encode late, and never trust a previous layer to have done enough.

Comparison: where to handle XSS defenses

There are a few places you can mitigate XSS in a Make-driven system. None of them are perfect alone.

1. Sanitize inside Make

You can strip tags, reject suspicious input, or normalize data before storing or forwarding it.

Pros

  • Stops obviously malicious payloads early
  • Reduces risk across every downstream consumer
  • Good place for basic allow/deny rules
  • Useful for workflows that syndicate content into many destinations

Cons

  • Make is not a full HTML sanitization platform
  • Regex-based filtering is fragile and easy to bypass
  • You can break legitimate content if users are allowed formatting
  • Sanitization policy in automation often drifts from app policy

A lot of teams start with something like this in a text function or mapper:

replace(replace(replace(1.body; "<script"; ""); "</script>"; ""); "javascript:"; "")

I don’t recommend trusting this. It catches toy payloads and misses real ones. Attackers don’t write payloads for your regex. They write payloads for browser parsing behavior.

If you must do filtering in Make, keep it limited to high-level controls:

  • reject content containing raw HTML when HTML is not expected
  • cap length
  • normalize suspicious Unicode if your downstream systems are weak
  • flag records for moderation instead of trying to “clean” them perfectly

2. Store raw input, encode at render time

This is usually the best default.

Make passes the data through, maybe validates type and size, but the application rendering the content handles output encoding based on context.

Pros

  • Correct security boundary: the renderer knows the output context
  • Works for HTML, attributes, JavaScript, URLs, and CSS separately
  • Preserves original data for review and forensics
  • Less chance of destructive sanitization

Cons

  • Requires every rendering app to be implemented correctly
  • Unsafe if any downstream system uses innerHTML or raw template output
  • Easy to fail in legacy admin tools and CMS widgets

This pattern works well when your app does proper contextual encoding.

For example, in a server-rendered template, this is usually safe:

<p>{{ customer_name }}</p>

This is not:

<p>{{{ customer_name }}}</p>

And on the frontend, this is safer:

element.textContent = untrustedValue;

This is where people get burned:

element.innerHTML = untrustedValue;

Make did not cause the XSS here, but it absolutely delivered the payload.

3. Sanitize in the destination application

If users are allowed to submit rich text, sanitize where that HTML is actually accepted and rendered.

Pros

  • Best place to apply a real HTML sanitization library
  • Easier to align with product requirements
  • Can enforce a precise allowlist of tags and attributes
  • Keeps business logic close to the rendering behavior

Cons

  • Every destination needs its own implementation
  • Inconsistent policy across apps is common
  • Internal tools are often forgotten and less secure than public apps

If your Make workflow sends content into a CMS, support portal, or admin dashboard that supports rich text, sanitize there with a proper parser-based sanitizer. Not with string replacement in Make.

4. Block inline script execution with CSP

Content Security Policy is not a replacement for escaping or sanitization, but it is a very useful backstop when something slips through.

If a Make automation ends up publishing untrusted content into a web app, a strict CSP can reduce exploitability.

Pros

  • Helps contain many reflected and stored XSS cases
  • Forces cleaner frontend patterns
  • Great defense-in-depth for automation-heavy stacks

Cons

  • Won’t fix unsafe HTML rendering
  • Weak CSPs are common and provide false confidence
  • Requires frontend and hosting coordination

A solid baseline looks more like this than the usual permissive mess:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-r4nd0m123';
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';

If you need implementation guidance, https://csp-guide.com is a good reference. For app-specific behavior, check your framework’s official documentation first.

Real-world failure patterns in Make scenarios

These are the ones I see most often.

HTML email preview reused in web UI

Teams build HTML email content in Make, then later show that same content in an internal preview page. Someone assumes “it’s just internal,” uses raw rendering, and stored XSS lands in an admin session.

CRM notes pushed into admin dashboards

Sales or support notes often contain copied content from external sources. Make syncs those notes into a dashboard. The dashboard renders them as HTML for formatting convenience. Bad idea.

Markdown converted unsafely

A workflow takes markdown from a form or AI tool, converts it to HTML, and publishes it. If the markdown renderer or destination allows raw HTML, you have an XSS problem.

Double decoding across systems

One tool encodes HTML entities, another decodes them, and the final app renders the result unsafely. Make workflows can hide this kind of transformation because each step looks harmless in isolation.

Safer patterns for Make automations

My opinionated checklist:

Treat every inbound field as untrusted

Even if it came from your CRM. Even if it came from an internal form. Even if another automation created it.

Use Make for validation, not magic sanitization

Good things to do in Make:

  • enforce schema
  • reject unexpected content types
  • strip dangerous content only when HTML is never allowed
  • route suspicious submissions for review

Bad things to do in Make:

  • build your own HTML sanitizer
  • rely on regex to remove JavaScript
  • assume one cleaned field is safe in every output context

Keep raw and rendered content separate

If a workflow transforms markdown to HTML, store both:

  • body_raw
  • body_html_sanitized

That makes reviews, debugging, and reprocessing much easier.

Render text as text by default

If a destination system does not require rich HTML, use plain text rendering everywhere possible.

titleNode.textContent = record.title;
descriptionNode.textContent = record.description;

That one decision kills a huge class of XSS bugs.

Sanitize rich content at the last responsible moment

If HTML is a product requirement, sanitize in the app that accepts and renders it, using a proper library supported by your stack.

Add CSP on anything that displays automation-fed content

Especially:

  • admin panels
  • moderation tools
  • CMS previews
  • internal dashboards
  • support consoles

Internal tools are usually where the slop lives.

What I’d recommend

If you use Make to move user-controlled content around, don’t ask “does Make prevent XSS?” That’s the wrong question.

Ask:

  • Where does untrusted data enter?
  • Where is HTML actually needed?
  • Which system renders the content?
  • Is output encoding context-aware?
  • Is rich HTML sanitized by a real parser?
  • Do we have CSP as a backstop?

My preferred model is simple:

  1. Validate shape and expected content in Make
  2. Reject or flag obviously unsafe input when HTML is not allowed
  3. Preserve raw data
  4. Sanitize only in destinations that intentionally support rich content
  5. Encode by output context at render time
  6. Deploy a strict CSP on any web UI that displays automation-fed data

That’s the practical balance. You keep the speed of Make without pretending automation glue can solve browser parsing security for you.