The first sign something was wrong was a workflow that should not have been running. I had a Webhook node sitting at the top of a client’s n8n instance, a simple one, POST request comes in, validates a shared secret in the header, passes the payload downstream to a Set node and then into their CRM. Standard stuff. I had built it six months earlier and it had been running without incident. Then I checked the execution log one afternoon for an unrelated reason and found forty-three executions from that morning that I had not triggered, all of them failing at the header validation step, all of them coming from the same two IP ranges, and all of them sending JSON payloads that were clearly probing the structure of whatever the webhook expected to receive.
Someone had found the endpoint. Not through any sophisticated means. The webhook URL was in a format that made it guessable if you knew the n8n URL structure and had a list of common workflow path patterns, which anyone who has spent time in the n8n community absolutely does.
I changed the webhook path, added rate limiting at the nginx level, and moved on. But I kept thinking about it, because the interesting part was not that it happened. The interesting part was how easy it had been to find. The URL structure for n8n webhooks follows a predictable pattern. If your instance is publicly accessible, and self-hosted instances often are because that is the whole point, the attack surface is not hidden. It is just sitting there, waiting for someone with a scanner and an afternoon.
This is the conversation the no-code automation space is not having loudly enough, and I think it is not having it because the platforms that would need to have it have marketing departments that have no incentive to start it.
Zapier runs everything on their infrastructure, which means their security posture is their problem and their liability. That is genuinely one of the things you are paying for, and it is not nothing. But it also means that when Zapier has an incident, every workflow on the platform is affected by whatever that incident was, and you find out from a status page update rather than from your own logs. You have visibility into what your workflows do but not into the environment they run in. That trade-off is fine until it is not.
Make.com has the same model with the same trade-off. I have spoken to people who moved to Make specifically because they wanted something cheaper than Zapier and did not want to self-host, which is a completely reasonable position. But Make’s credential storage has had enough reported oddities over the years that I would not store anything sensitive in it without asking hard questions about their encryption and access control implementations, and the documentation on those questions is not detailed enough to answer them properly. I tried. The support article says credentials are encrypted at rest. It does not say where the encryption keys live or who has access to them.
With n8n self-hosted you own that problem entirely, which is either reassuring or terrifying depending on how you feel about owning your own problems. What I know from running instances on EC2 is that the default Docker Compose setup in the documentation is not a production security configuration. It is a get-it-running configuration. The documentation at the time I set up my first production instance did not make that distinction clearly enough. It walked you through getting n8n accessible on the internet without a meaningful section on what you should lock down before you did that. I added HTTP basic auth on the nginx layer, restricted the webhook paths to expected patterns, and set up fail2ban on the instance because I had seen enough failed SSH attempts to know what unprotected infrastructure attracts. None of that was in the official docs. I assembled it from forum posts and a GitHub issue thread from 2022.
The actual vulnerability landscape for these platforms is broader than most users think about. Webhook endpoints are the obvious one, but credential exposure through misconfigured environment variables is the one that keeps me careful. n8n stores credentials in its database, and if that database is on the same instance as the application and someone gets a shell through an unpatched dependency, the credentials are in the same place as the breach. I keep the n8n database on a separate RDS instance now. More expensive, more complex, and not mentioned anywhere in the standard deployment guide.
LangChain integrations have added a new dimension to this that I find genuinely concerning. I have built flows where an LLM node processes external input, and the prompt injection risk in that pattern is real and underappreciated. If your workflow takes user-submitted text and passes it into a prompt without sanitisation, someone can craft input that manipulates the model’s behaviour and potentially the downstream actions the workflow takes. I have not seen this weaponised against an n8n flow in the wild yet. I expect to eventually.
The no-code platforms built their growth on the promise that anyone could automate anything without needing to understand the infrastructure underneath. That promise was always a simplification, but it was a useful one when the workflows were connecting a spreadsheet to an email. It becomes a different kind of simplification when the workflows have API credentials for fifteen services, process sensitive business data, and are reachable from the public internet on a guessable URL.
The honest position is this: your automation platform is infrastructure, and if you have not been treating it like infrastructure, including the security posture, the access controls, the credential hygiene, and the exposure surface, then you have been hoping that obscurity would do the work that configuration should be doing.
Obscurity stopped working the moment someone built a scanner that knows what n8n webhook URLs look like.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.