Chatbot Endpoint Security

9/27/2025

D

By David Karim

Implementing secure API endpoints

Introduction

A simple API endpoint architecture that appears to be secure is often open for bad actors who could cause damage through various means. Let's look at one example where an API endpoint does not have adequate security.

Although orchestration tools (such as n8n shown here) offer some security features, these may often times not be enough. The webhook settings for the configuration above is shown below. The Allowed Origins (CORS) option has been configured here and it does provide some security benefits. It prevents others from implementing code in their own website that can make requests to this webhook. The server will now send an Access-Control-Allow-Origin value in the header response to ensure the request only comes from a legitimate source. It is the browser's job to block unauthorized cross-domain requests.

CORS is only one layer of security. Anyone who finds out what your endpoint address is, can simply send requests using curl commands or with a tool like Postman. Because the browser is the piece blocking cross-domain requests, CORS will not block requests from other tools.

We can also see that the request body in this example is sending an API key which can help provide another layer of security, but those credentials should never be stored in code that is running on a browser. If the API request is originating directly from the browser, then the API keys are exposed.

A More Secure Solution

Let's have a look at a more secure workflow. This workflow checks the API key first and only proceeds to the AI Agent if it matches the key stored in the Data Table. But more needs to be done.

This doesn't help to resolve the problem of how the browser can send API keys when it initiates a request. Let's define the additional security features that need to be implemented.

• The browser code which originates the request should never send the request directly to the workflow webhook. A separate API endpoint acting as middleware (and running on a secure server) can store the API key instead.
• The new API endpoint will also implement an Allowed Origins check. We can now be sure that the workflow will only receive requests from the API endpoint. But anyone could still send curl or Postman requests to the API endpoint. This is where CSRF tokens come in.
• CSRF tokens are implemented via a separate endpoint in the API server. The moment the browser code runs, it will request a CSRF token from the API server (Allowed Origins checks are in place here also). When the browser sends a request meant for the Chatbot workflow, it will now send the CSRF token to the API server along with the actual chatbot request. The server will check the validity of the token and only proceed if the token is valid. The token can then be discarded and a new token can be sent to the browser to mitigate replay attacks.
• Rate limiting implementation running on the API server. Another critical feature is IP-based rate limiting. A reasonable rate request limit can help with spam and abuse but also can help with denial of service attacks.

Security Is Critical

Although it might be tempting to forgo a more robust solution, it is never a good idea to have insecure API endpoints especially if they allow others to run expensive back-end code or if the endpoint has access to a database.

If you would like to talk to us about implementing secure AI solutions for your business, just contact us via our chatbot here.