Skip to main content
Question

Securing automations - looking for input/best practice

  • September 5, 2025
  • 2 replies
  • 45 views

virtualcitymatt
Celebrity
Forum|alt.badge.img+47

I’ve been working on a service which is to be triggered by a webhook. 

The process ends with an email to the initial requester with a link to the data where they can download it from. 

On of the things I want to include was/is a summary of the request to help the user figure out what it is they requested when they look at the email. But that requires me consuming and then giving back the user their own input. In testing I’ve found that it’s really easy to just inject key words into the request. There are certain key words that just get resolved directly meaning I couldn’t even try and sanitize the request. 

Is this a lost cause? Has anyone else battled with this?

For example if the request was something like
 

{
    “parameter1”: “{event.id}”
}

Then {event.id} just gets resolved and if I’ve using “parameter1” in my email then it just gets set out as the event id.
 

2 replies

ebygomm
Influencer
Forum|alt.badge.img+44
  • Influencer
  • 3434 replies
  • September 5, 2025

Do you see the same behaviour if you construct the email content within a workspace and send it via an automations writer?


virtualcitymatt
Celebrity
Forum|alt.badge.img+47
  • Author
  • Celebrity
  • 2000 replies
  • September 5, 2025

Do you see the same behaviour if you construct the email content within a workspace and send it via an automations writer?

Yeah, I do because the content of the "webhook.message" gets resolved before it even hits the workspace - so unless I check that it contains an allowed value there's no way for me to avoid it.