Host a chatbot on your website, safely

Learn in your browser · Chapter 01 of 06

The most important rule of hosting a chatbot is that the browser never talks to the model provider directly. Everything else in this workbook follows from that rule.

Anything that reaches a visitor's browser is public. The page's code, the requests it makes and any key inside it can be read by anyone who opens the browser's developer tools. So a key placed in front-end code is not a secret. Someone can copy it and spend your money.

The safe pattern puts a small piece of your own code in the middle. The browser sends the visitor's message to your server function. Your function holds the key, checks the request, adds the system prompt, calls the model and returns the reply. A serverless function is a small piece of server code that a hosting platform runs on demand, so you do not manage a server.

Browser  --message-->  Your function  --request + key-->  Model API
(public)               (private)                          (provider)
Browser  <--reply----  Your function  <--reply-----------  Model API

Scroll sideways to see every column.

Learn in your browser · Chapter 02 of 06

A public chat box will be found by people who want free answers and by scripts that try everything. Plan for abuse before launch.

Scroll sideways to see every column.

Input validation means never trusting what arrives. Check the method, the shape of the data, the number of messages, the length of each and the roles allowed. Accept only user and assistant messages from the browser. Never accept a system message or a model name from it.

Rate limiting counts requests per visitor over a time window and refuses the excess with a friendly message. Use the visitor address your host supplies, because headers a client can set are easy to fake. A counter held in one function instance is not shared and resets, so real deployments use a shared store or a platform feature.

CORS (cross-origin resource sharing) is a browser rule: a page from one origin may not read replies from another origin unless that server allows it. If your page and function share an origin, you need no CORS settings. If they differ, allow only your own site's origin rather than a wildcard.

Cost control works in layers: a cap on each reply, a cap on messages per visitor, a daily cap for the whole site that switches the bot to its fallback message, alerts when spend rises, and a kill switch you can flip quickly.

Learn in your browser · Chapter 03 of 06

Here is a complete, small example. Both parts are illustrative: adapt names, headers and response shapes to your provider and your host.

// Illustrative serverless function using standard Request and Response objects.
// MODEL_API_URL, MODEL_API_KEY and ALLOWED_ORIGIN are environment variables.
const SYSTEM_PROMPT = "You are the help assistant for an imaginary bakery. ...";
const LIMITS = { messages: 20, chars: 1000, replyChars: 4000, perMinute: 10 };
const hits = new Map(); // per instance only: use a shared store, which also holds a daily cap

const cors = {
  "access-control-allow-origin": process.env.ALLOWED_ORIGIN,
  "access-control-allow-methods": "POST",
  "access-control-allow-headers": "content-type",
  "vary": "Origin",
};
const send = (status, body) =>
  new Response(body ? JSON.stringify(body) : null, {
    status,
    headers: { ...cors, "content-type": "application/json" },
  });

function rateLimited(ip) {
  const now = Date.now();
  const entry = hits.get(ip);
  if (!entry || now > entry.resetAt) {
    hits.set(ip, { count: 1, resetAt: now + 60000 });
    return false;
  }
  entry.count += 1;
  return entry.count > LIMITS.perMinute;
}

function validMessages(list) {
  return Array.isArray(list) && list.length > 0 && list.length <= LIMITS.messages &&
    list.every(m => m && ["user", "assistant"].includes(m.role) &&
      typeof m.content === "string" && m.content.length > 0 &&
      m.content.length <= (m.role === "user" ? LIMITS.chars : LIMITS.replyChars)) &&
    list[list.length - 1].role === "user";
}

export default async function handler(request) {
  if (request.method === "OPTIONS") return send(204);
  if (request.method !== "POST") return send(405, { error: "Method not allowed" });
  if (process.env.BOT_ENABLED === "false") return send(503, { error: "The assistant is switched off." });
  if (request.headers.get("origin") !== process.env.ALLOWED_ORIGIN)
    return send(403, { error: "Forbidden" });

  // Use the visitor address your host documents. Some hosts overwrite x-forwarded-for;
  // if yours appends to it instead, the first entry can be faked by the client.
  const ip = (request.headers.get("x-forwarded-for") || "unknown").split(",")[0].trim();
  if (rateLimited(ip)) return send(429, { error: "Too many messages. Please wait a minute." });

  let body;
  try { body = await request.json(); } catch { return send(400, { error: "Bad request" }); }
  if (!validMessages(body?.messages)) return send(400, { error: "Bad request" });

  try {
    const upstream = await fetch(process.env.MODEL_API_URL, {
      method: "POST",
      headers: {
        "content-type": "application/json",
        "authorization": "Bearer " + process.env.MODEL_API_KEY,
      },
      body: JSON.stringify({
        messages: [{ role: "system", content: SYSTEM_PROMPT },
          ...body.messages.map(({ role, content }) => ({ role, content }))],
        max_output_tokens: 300,
      }),
      signal: AbortSignal.timeout(15000),
    });
    if (!upstream.ok) throw new Error("upstream status " + upstream.status);
    const data = await upstream.json();
    const reply = typeof data.text === "string" ? data.text.trim().slice(0, LIMITS.replyChars) : "";
    if (!reply) throw new Error("empty reply");
    return send(200, { reply });
  } catch {
    return send(502, { error: "The assistant is unavailable." });
  }
}

Read it for the pattern. The function answers the browser's preflight check, refuses anything but a POST whose Origin header is your own site (a script can fake that header, so it is a filter, not a lock), honours a kill switch, limits the rate, validates every message and passes on only its role and text, adds the system prompt itself, caps the reply, times out slow calls and turns any failure into one friendly message. It never passes provider error text to the visitor, and it logs no message content.

<div id="log" role="log" aria-live="polite"></div>
<form id="chat">
  <label for="msg">Your message</label>
  <input id="msg" maxlength="1000" autocomplete="off" required>
  <button type="submit">Send</button>
</form>
<script>
  const log = document.getElementById("log");
  const turns = [];

  function add(who, text) {
    const p = document.createElement("p");
    p.textContent = who + ": " + text;  // textContent, never innerHTML
    log.appendChild(p);
  }

  document.getElementById("chat").addEventListener("submit", async (event) => {
    event.preventDefault();
    const box = document.getElementById("msg");
    const text = box.value.trim();
    if (!text) return;
    box.value = "";
    add("You", text);
    turns.push({ role: "user", content: text });
    try {
      const res = await fetch("/api/chat", {
        method: "POST",
        headers: { "content-type": "application/json" },
        body: JSON.stringify({ messages: turns.slice(-19) }),
      });
      if (!res.ok) throw new Error("bad status");
      const data = await res.json();
      turns.push({ role: "assistant", content: data.reply });
      add("Assistant", data.reply);
    } catch {
      turns.pop();
      add("Assistant", "Sorry, I cannot answer right now. Please email the team.");
    }
  });
</script>

Two details matter. The reply is added with textContent, never innerHTML, so any markup in a reply is shown as text and cannot run as code. And the log region has a role and aria-live setting, so screen readers announce new messages.

Streaming lets the model send its reply in pieces and your function pass them on, so words appear as they are written. The bot feels faster. A browser can read such a stream using server-sent events (see Sources) or by reading a streamed response. Streaming adds work: a dropped connection can leave half a reply, you cannot check the whole reply before showing it, and cost accounting must handle partial replies. Get the plain version working first.

Learn in your browser · Chapter 04 of 06

This chapter is general information in plain terms, not legal advice. If a visitor types anything about themselves, and in a free text box they will, UK data protection law is likely to apply to what you do with it.

The Information Commissioner's Office (ICO) explains that people have a right to be told how their data is used (see Sources). In practice, show a short notice next to the chat box that says:

• who you are and how to contact you
• that the visitor is talking to an automated assistant, not a person
• what you do with what they type, and why
• who else receives it, which includes the model provider your function calls
• how long you keep it
• where to find your full privacy notice, and a request not to type sensitive details

Collect the least you need. Not every chat needs consent as its legal basis, and cookies and similar technologies fall under separate rules, so check the ICO's guidance for your situation. If the bot may handle children's data, health details or other sensitive information, get proper advice before launch.

Scroll sideways to see every column.

Whichever you choose, check your model provider's data settings. Messages you send them may be kept or used under their terms, and you should tell visitors the truth about what happens.

Learn in your browser · Chapter 05 of 06

A chatbot that some people cannot use, or that fails silently, is a poor front door. These four habits make yours dependable.

Accessibility. The Web Content Accessibility Guidelines (WCAG 2.2, see Sources) describe what good looks like.

• Give the input a real label, and make every control reachable and usable by keyboard, with a visible focus outline.
• Announce new replies to screen readers with a live region. WCAG has a success criterion on status messages for this idea.
• Do not trap keyboard focus in the widget. Let people close it with the Escape key.
• Keep good colour contrast, let text resize, and respect the reduced-motion setting for animations such as typing dots.
• Give errors in words, not only colour, and always offer a route that is not a chat, such as email or a form.

Fallbacks and human handover. The bot will sometimes be unavailable: the provider is down, a limit is reached, the kill switch is on. The chat window should say so and offer another route. Keep a way to reach a person visible at all times. Do not trap visitors in a loop with a bot, be honest about response times, and offer to send a transcript to your team only with the visitor's permission.

Monitoring. Watch a small set of numbers: requests per hour, error rate, response time, spend per day, rate-limit hits, how often the bot declines or hands over, and visitor feedback. Set alerts for spend and error spikes. Write down the leaked-key procedure before you need it: revoke the key at the provider straight away, create a new one, update the function's environment and check recent usage.

Learn in your browser · Chapter 06 of 06

Run this list against the live site, not just your own computer, and only launch when every line is a yes.

• The key exists only in the function's environment, not in the page, the repository or the logs.
• The function refuses the wrong method, the wrong origin, oversize input and malformed input.
• The system prompt, the model and the reply cap are set on the server.
• A rate limit, a daily cap, a provider spending limit and an alert are in place.
• The kill switch works, and the fallback message and human route show when it is on.
• Model output is displayed as text, never as HTML.
• The privacy notice sits next to the chat, retention is decided and provider data settings are checked.
• A keyboard-only run and a screen-reader run both pass.
• Your test set from the previous workbook passes against the live site.
• Monitoring and alerts are on, and the leaked-key steps are written down.

Launch quietly to a small group first, watch the numbers, then widen it. Your chatbot is only as trustworthy as the least careful thing around it. To let it answer from your own documents with sources, read RAG and knowledge bases next.