Audit your n8n instance
An n8n instance rots quietly. Somebody duplicates a workflow to try something and the copy stays. A key gets pasted into an HTTP header because the credential dropdown was two clicks away. Nothing breaks today, so nobody looks. I pointed this at my own instance, it scored me 61 out of 100, and it found a live API key sitting in plain text that I did not know was there.
The questionHow do I audit my n8n instance for hard-coded secrets, open webhooks and duplicate workflows?
How the working version is put together
Read the instance, change nothing
It points at your instance through the official n8n API with a read key and never writes. It does not activate, deactivate, edit or delete anything. Out the far end comes one flat row per workflow plus a summary row for the instance itself.
Hunt the secrets sitting in node parameters
Credential-shaped strings in the places a credential should never be: API keys, bearer tokens, database connection strings with a password in them, and any field named for a key or a password that has a long literal assigned to it. This is the check that found a live API key on my own estate.
Check what the webhooks and the error paths let through
Webhook triggers with authentication set to none, and whether the path is a guessable word or a random one. Then the quieter half: workflows with no error path at all, so a break tells nobody, and nodes configured to carry on past a failure with nothing downstream to catch it, so the failure vanishes without trace.
Find the copies, the corpses and the pinned data
Duplicate and near-duplicate workflows, including the ones whose node graph matches another exactly under a different name. Workflows switched on that have never run, and ones switched off and untouched for a year. Pinned editor data still attached to a live workflow, which is the classic works-in-the-editor and lies-in-production fault. Credentials that no workflow references at all.
Score it, and name five things to fix first
The score is a rate rather than a count, so a large instance is not condemned for being large. Underneath it sits the honest part: a ranked list of the five things worth doing first, written as plain sentences. A hundred findings with no order is a report nobody opens.
What it found on my own estate
It audited 88 workflows in one pass and scored the instance 61 out of 100. Thirteen workflows exposed a webhook with no authentication. Fourteen groups of duplicates, one of them four copies of the same job. Fifty-one workflows had no error path, and nineteen nodes were configured to swallow a failure silently. There were credentials sitting there that no workflow referenced.
And a live API key in plain text inside a node, which I had no idea was there. The estate looked completely fine from the outside, and that is the whole reason this page exists. I fixed all of it. Moving the flagged keys into proper credentials on its own took the score from 61 to 63, which tells you how much of the damage was everything else. Every number here was measured on my own operations. I have no customers for this tool and nothing on this page comes from a client.
The false alarm I had to fix first
The first version read a key's type from the header name and the shape of the string, and on that basis it called a Supabase anon key a service-role key. Those are not the same thing at all. An anon key is public by design, ships in the browser bundle of every Supabase app, and is fenced in by row-level security. A service-role key bypasses that entirely.
One of those is an emergency and the other is a tidy-up, and a security tool that cannot tell them apart is worse than no tool, because it teaches you to ignore it. So it decodes the token's own claims and classifies from those instead of guessing at the string. It reads the expiry too, and reports a token with no expiry as exactly that. It never emits any part of the token itself: only the claims, capped in length.
The other half of the question
This one asks how your workflows are built and how they are secured. My other Actor, the silent-success watchdog, asks whether they still produce anything, which is the failure that hides among green ticks. Neither shows up in the executions list, and neither catches what the other catches.
The pairing I actually run is this audit quarterly and the watchdog daily. One tells you the estate is built badly. The other tells you a workflow stopped producing while still reporting success.
What it costs to run
Half a cent per workflow audited. Every check runs inside that one charge, so switching more of them on does not cost more. There is no browser and no proxy behind it, so the platform usage on top is small. Run it with no key and you get a demo audit, which lets you see the output shape before connecting anything real.
The limits are worth reading before you trust a clean result. It audits what the API exposes, and different n8n versions expose different things. Secret detection is pattern based, so it finds shapes rather than meanings and will miss a key in a format it has never seen. It never sends a request to your webhooks and never tries your credentials, so nobody should read it as a penetration test, and it certainly is not legal advice. Treat a finding as a place to look rather than a verdict.
When I would tell you not to bother
If you have six workflows and you built all six last month, you already know what is in them. This finds what accumulates over a year in an estate nobody has read end to end.
If you want proof that nobody can get in, this is not that and cannot be. It reads configuration from the outside of the workflow and never probes anything. A clean audit means the shapes it knows about are not there. It does not mean you are secure.
What lands on your desk
- One row per workflow, with every finding graded high, medium or low and written as a sentence
- Secrets found in node parameters, with the node and the parameter named and the value never printed
- Unauthenticated webhooks, duplicate groups, dormant workflows and missing error paths
- A hygiene score and the five things worth fixing first, in order
- If you want the estate cleaned up, the keys moved and alerting wired in, that is the work I do
Open the proof
Published case studies of systems that are running. Each links to the thing itself.
The silent-success watchdog Actor on Apify ↗My n8n creator profile ↗
Questions this page answers
- What did it find on your own instance?
- It audited 88 workflows and scored the instance 61 out of 100. Thirteen workflows exposed a webhook with no authentication, there were fourteen duplicate groups including four copies of one job, fifty-one workflows had no error path and nineteen nodes swallowed failures silently. It also found a live API key in plain text that I did not know was there.
- Does it print my secrets in the output?
- It never prints them. A finding names the workflow, the node and the parameter, plus the class of thing that matched. For a token it reports the decoded claims, capped in length, and never any part of the token itself.
- How does it avoid crying wolf over a public key?
- The first version read a key's type from the header name and the string shape, and called a Supabase anon key a service-role key. An anon key is public by design and fenced by row-level security. It now decodes the token's own claims and classifies from those, and it reads the expiry as well.
- How is this different from the silent-success watchdog?
- This one audits how workflows are built and secured. The watchdog audits whether they still produce anything. I run this quarterly and the watchdog daily, because neither failure shows up in the executions list.
- Is it safe to point at a production instance?
- It reads through the API and writes nothing back, so it never activates, deactivates, edits or deletes anything on your instance. It also never sends a request to your webhooks and never tries your credentials, which is why nobody should mistake it for a penetration test.
Want this built and handed over working?
One line is enough to start. You get an honest answer on fit, and a number rather than a discovery call.
Start a brief