No. Treat data from a connected app as untrusted input, the same as a web form. A record in a third-party tool can be edited by customers, partners or an attacker, and an automation that passes it along unchecked can store, run or forward something harmful.
Why people over-trust connectors
A connector feels like a pipe between two trusted systems. But the fields flowing through it often began as free text typed by someone outside your company: a support ticket subject, a form answer, a company name, a repository title. OWASP's API Security Top 10 names this pattern Unsafe Consumption of APIs. Its description says developers tend to trust data from third-party APIs more than user input, and so apply weaker validation and weaker transport security.
Three scenarios from OWASP
- Poisoned enrichment data. An API stores address data from a third-party service in a database. An attacker plants an injection payload in a record at that service. It is stored without sanitizing and runs later.
- Redirect abuse. A third-party storage service responds with a redirect. The integration follows it blindly and resends sensitive data to the attacker.
- Malicious metadata. An attacker names a repository with a payload. An integration trusts the name and builds a database query from it.
The same shapes appear in low-code flows. A spreadsheet step that writes a cell beginning with an equals sign, an email step that uses a ticket subject in a subject line, or a script step that builds a command from a field are all the same mistake.
Checklist
| Check | Why |
|---|---|
| Define the expected type, length and character set for each field | Stops oversized or odd input |
| Escape or parameterize before using a value in a query, command or formula | Stops injection |
| Do not follow redirects blindly, and keep an allowlist of destinations | Stops data being resent elsewhere |
| Require TLS for every connector call | Protects data in transit |
| Set timeouts and size limits on responses | Stops one slow or huge reply stalling the flow |
| Reject unknown event types and fields | Keeps the flow to what you designed |
| Log rejected records for review | Makes attacks visible |
These match the prevention list in the OWASP entry: assess the provider's security posture, require TLS, validate and sanitize data from integrated APIs, and allowlist redirect destinations.
Bound what an automation can do
Validation will miss something eventually, so limit the damage too.
- Give each flow the least privileged connection that works.
- Keep write actions, such as sending money, deleting records or emailing customers, behind an approval step.
- Do not let a field's content decide which action the flow takes unless the options are a fixed list.
- If a flow includes an AI step, treat the incoming text as instructions an attacker may have written, and keep the step away from sensitive connections.
Quick check
Is data from a well-known vendor safe by default?
No. The vendor may be reliable, but the content inside the fields can come from anyone who can write to that tool.
Where should validation happen?
At the point your automation receives the data, before it is stored, displayed or passed to another system.
Safeguard's API security scanning and dependency scanning can help check your own services that receive this data. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
