There are no secrets in the frontend

How secure is your workflow as a backend?

Can you use an n8n workflow or a Make scenario as a backend or an API for your frontend?

I have been thinking about this lately.

I have built a dashboard which uses a couple of n8n workflows in the backend to provide the data.

Now I want to run this in the cloud, but there is a problem.

The dashboard is a React app which calls an n8n Webhook directly from the frontend. Currently it's running locally but if this goes in the cloud as it is, the webhook URL will be exposed. Potentially could be misused or abused!

The Nature of Frontend Code

When you build a web application, the frontend is what users interact with in the browser - the buttons they click, the forms they fill out, and the pages they see.

The backend is where the real magic happens - handling data, authenticating users, and processing logic that shouldn’t be exposed to the world.

When using a workflow as a backend, we use a webhook to trigger the workflow which should be called from the frontend.

In n8n there are several ways you can Authenticate your webhook, which is great.

Yes, you can secure your webhook. The problem is "There are no secrets in frontend!".

Along with the webhook URL, the authentication tokens are out there too!

Frontend Code is Fully Exposed

Think of your frontend like a public bulletin board. Anyone can see what’s pinned there. Your JavaScript, HTML, and CSS all get sent to the user’s browser, and once it’s there, they can inspect and manipulate it however they want.

Let’s say you write some JavaScript code like this:

fetch('https://example.com/webhook', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer SECRET_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ message: 'Hello webhook!' })
});

Any user can open their browser’s Developer Tools (DevTools) and see this API key in plain text.

Now, they can copy it and use it anywhere, maybe in a script that spams your webhook 10,000 times, or worse, accesses sensitive data.

Bottom Line: Frontend is NOT a Safe Place for Secrets

If you put a secret in your frontend, whether it’s an API key, token, or password, you should assume that anyone can and will find it.

Webhooks should always be called from a secure backend, where you can enforce authentication, rate limits, and other security measures.

Never trust the frontend with secrets - tokens, API keys, and passwords are always visible.
Never assume a request only comes from your UI - attackers can send requests from anywhere.
Never expose a webhook without protection - or you risk spam, abuse, or server crashes.

Can CORS and IP whitelisting help?

Cross-Origin Resource Sharing (CORS) restrictions will not prevent unauthorized calls.

CORS only applies to browsers, it does not prevent an attacker from copying the request and sending it using Postman, cURL, or a server-side script.

Even with strict CORS settings, an attacker can still make the request from anywhere outside the browser. So, yeah enabling CORS might stop some casual abuse, it does not protect your webhook from direct misuse.

What about IP Whitelisting?

IP whitelisting only works if your webhook is meant to be called from a known source (like your own server). 

If your webhook needs to handle requests from multiple unknown clients (like a public API), then IP whitelisting isn’t practical.

So what do you do?

I'm looking at different options like, a reverse proxy or an API gateway. Let's see how it goes.

If you have successfully implemented a secure solution, I would love to hear about it.